Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

OS 설치 정책

아주 간단히만 말을 하면 표준화된 OS설치를 위해서 표준화된 하드웨어 사용이 필요하고 OS설치 전 새로운 서비스라면 사전에 각종 설정 정책부터 정리를 해야 합니다.
여기에는 파티션도 포함이 되어 있습니다. OS설치하는 단계부터 표준화를 하고 파티션도 kickstart 과정중에 자동으로 만듭니다.
설치 후 puppet 같은 시스템 설정 도구를 이용하는 경우 자동으로 설치하고 기본 설정은 OS설치하는 작업만으로 모두 마치면 됩니다.

파티션 같은 경우에는 kickstart 에서 pre 항목에 지정하면 현재 가지고 있는 디스크 갯수, 디스크 타입을 체크하여 자동으로 원하는 파티션 만들 수 있습니다.
요즘은 대용량 디스크가 많으므로 tune2fs 프로그램을 이용, OS 디스크말고 데이터 디스크는 reserved-blocks-count 값을 변경합니다.
또한 디스크 IO성능을 위해 일부 값을 변경합니다.
설치 후 후속작업은 post 설정에 모든 내용을 넣습니다. 파티션 등 OS 설치단계에서 지정해야 하는 내용을 빼면 설치 후 ACL 설정정도 하면 되고 설치 후 자동으로 puppet 으로 모든 설정을 하면 됩니다.

대규모 설치가 필요한 경우는 pxe 기능을 이용하면 됩니다. 리눅스든 아니면 윈도우 PC에 tftp, dhcp, http/ftp 등 올려서 사용하면 됩니다.
데비안의 경우는 preseed 이용하면 됩니다.
규모가 큰 회사의 경우 각 IDC별로 tftp, dhcp를 올릴 수도 있고 네트워크 장비가 지원을 하는 경우에는 dhcp relay 기능을 이용하면 굳이 각 서브넷별로 dhcp 서버를 올릴 필요는 없습니다.

윈 도우의 경우는 WDS를 이용하여 자동설치할 수 있습니다. WDS도 어차피 동일한 기술을 이용합니다. kickstart 나 preseed 처럼 사전에 설정파일을 만들면 되고 WDS 에서 tftp, dhcp 등을 올릴 겁니다. PXE를 이용한다면 윈도우도 PXE로 부팅하고 나서 미리 정의한 시스템 설정을 고르기만 하면 자동으로 OS설치됩니다. 마찬가지로 설치 후 후속작업도 스크립트등으로 해 놓으면 전체 과정을 자동화할 수 있지요. 아주 예전 윈도우 2008로 테스팅을 했을 때는 자동설치 정보도 AD에 들어가기 때문에 vbs나 powershell 등으로 스크립트를 짜서 AD정보를 업데이트 했었습니다.

글로벌하게 구상을 한다면 kickstart 서버도 CDN서비스를 이용하여 global cache 를 사용하면 각 나라별로 가까운 캐쉬서비스를 이용하므로 속도도 보장할 수 있습니다.
물 론 이런 경우에는 acl을 관리해줘야 합니다. 현재 저는 회사에서 관리하는 전체 네트워크 정보를 api를 이용해 가져와 puppet 에서 변수로 설정을 한 다음 자동으로 kickstart 서버에서 acl을 업데이트하도록 구현했습니다.(전체 acl 정보는 한곳에서 변수로 관리하고 acl 정보가 업데이트가 된 경우 puppet 에서 알아서 한꺼번에 모든 acl을 업데이트합니다. apache, iptables 등등)

설치를 모두 마치면 마지막에 이메일를 보내서 설치완료를 확인할 수 있도록 하고 특정파일에 로그를 남겨놓습니다.

물론 신규 시스템을 준비하는 경우 가상화 환경이라면 이미지 하나 복사하는 방식을 쓸 도 있겠지요.
그렇지만 kickstart를 쓴다고 하더라도 자동화된 인프라를 해 놓으면 시간이 더 걸리는것도 아닙니다.

Re-kickstart

이미 리눅스OS가 설치되어 ssh나 콘솔로 접근할 수 있다면 손쉽게 CD나 PXE 부팅 없이 OS를 재설치할 수 있습니다. (kickstat는 미리 준비되어있다는 가정하에서)

CD로 부팅을 하건 PXE로 부팅을 하건 부팅시 부트 이미지를 가져오면 되지요.
vmlinuz,initrd.img 이미지를 다운로드 받아서 /etc/grub.conf 에 해당 kickstart 설정을 해주고 재부팅시 grub 에서 이 부분을 고르도록 설정해 놓습니다.
그러면 재부팅을 하면서 자동으로 kickstart 를 실행하면서 OS를 재설치 할 수 있습니다.
아래에서 ip, netmask, gateway, myhost(호스트네임) 등은 현재 시스템것을 그대로 쓰면 되겠지요.
 
wget http://mirror.centos.org/centos-5/5/os/x86_64/images/pxeboot/vmlinuz -O /boot/vmlinuz-ks
wget http://mirror.centos.org/centos-5/5/os/x86_64/images/pxeboot/initrd.img -O /boot/initrd-ks
/sbin/new-kernel-pkg --initrdfile=/boot/initrd-ks --banner="Re-Kickstart" \
--kernel-args="ksdevice=eth0 ks=http://example.comks.php \
ip=$ip netmask=$mask gateway=$gateway dns=164.124.101.2 myhost=$myhost" --install ks

원격콘솔이 있는 경우에는 원격콘솔에서 제대로 설치가 되는지 확인할 수 있습니다.
원격콘솔이 없는 경우에는 kickstart 설정에서 원격으로 syslog를 보낼 수 있으므로 원격에 syslog 서버를 마련하여 디버깅 자료를 볼 수 있습니다.

centos를 쓰는 경우 centos 5. 를 쓰는 곳도 있고 centos 6을 쓰는 분들도 있을건데요.
조금 철지난 이야기이기는 하지만 팁 차원에서 이야기를 하면요.
centos 5.6 부터는  kickstart 레포지토리에 접속이 안 될 때 자동으로 여러 번 시간 간격을 늘리면서 접속 시도를 합니다. (4-5분정도임)
이전의 anaconda 프로그램에서는 시간 간격 없이 kickstart 레포지토리에 접속시도를 하기 때문에 일시적으로 네트워크 이상 등이 있는 경우 OS 설치가 실패할 가능성이 높습니다.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/5.6_Release_Notes/index.html
OS 설치는 centos 5.6 이하의 것을 이용하되 부트 이미지만 5.6 이상으로 바꾸어서 사용가능합니다.
kickstar 설치시 anaconda 프로그램에서 자기것과 kickstart yum repo의 os/x86_64/images/pxeboot 이미지가 같은지 확인하기 때문에 자체적으로 yum repo를 운영한다면 이 이미지 디렉토리만 업데이트해주면 되거든요...

마무리 하겠습니다.
- 기술적으로는 자동으로 OS를 설치하기 위한 인프라를 구축해 놓는다. OS 설치 후 설정은 시스템 설정 도구를 이용하여 자동화한다.
- 정책적으로는 표준적인 하드웨어, 표준 KICKSTART 프로파일, 표준 시스템 설정을 마련한다.

kickstart 기타 이야기

지난 주에 kickstart 에 대해서 이야기를 했는데 설명을 했지요.
kickstart 자체야 문서도 많으니 각 옵션들 세부적으로 살펴보시면 도움될 것들이 있습니다.
(예를 들어 swap 설정도 메모리 크기에 따라 자동으로 조정하는 옵션 등을 사용할 수 있음)
이 설정도 표준화를 해서 써야겠고 디스크 파티션, 마운트 포인트, 파티션 타입 등로 표준화해서 사용을 하시는 게 좋습니다.
몇가지 사전에 kickstart 프로파일을 정의해 두어야죠.
pre 설정에서 디스크 타입, 디스크 갯수 등의 정보를 뽑아낼 수 있기 때문에 OS 디스크말고 데이터용으로 쓸 디스크 갯수에 따라 파티션을 자동으로 구성하면 편리합니다.

post install 과정도 무엇이든 넣을 수 있기 때문에 puppet 같은 프로그램에서 관리하는 것에 포함되지 않는 작업들을 포함시켜 놓으면 좋습니다. 예를 들어 원격접속을 위한 IPMI 설정도 kickstart 과정에서 동일하게 설정을 해 놓습니다.

사전에 부팅 이미지를 복사하고 grub.conf 를 설정하여 OS재설치를 손쉽게 하는 부분도 kickstart 에 포함을 해 두었습니다. 그러면 이미 OS가 설치되어 있는 경우 OS재설치시 grub.conf 에서 순서만 바꾸면 바로 재설치할 수 있습니다. 간단하면서도 매우 유용한 팁입니다.

yum 배포정책, rpm

OS는 CentOS에 기반을 두되 커스터마이징해서 사용하고 있습니다. bash, openssh 같은 프로그램들의 일부 소스를 고쳐서 쓰고 있는데 (나중에 다른 것 이야기하면서 시간되면 소개해 드리겠습니다) 일반적인 경우에는 배포폰 자체를 고쳐쓸 일은 없을 것입니다. 커스터마이징해서 사용할 수는 있는데 계속 관리하기 쉽지 않아서요.
yum repo 는 외부에 있는 것 설정하지 않고 우리 자체 yum만 사용을 합니다. 외부에 있는 것을 쓰면 관리하기가 힘들고 일관성을 잃게 됩니다.
또한 최대한 새로 설치하는 프로그램들은 rpm 포맷으로 관리합니다. 물론 자체적으로 계속 rpm 을 관리해야 하는 부담간은 있지만 그래서 일관되게 관리할 수 있습니다.
yum repo 설정이나 rpm 설치 등도 모두 puppet 에서 관리하기 때문에 이렇게 일관된 관리가 가능합니다.
system configuration 도구를 이용하여 모든 시스템 설정을 관리하지 않는다면 이렇게 일관된 관리가 힘들고 해당 팀에서, 담당자가 알아서 관리하게 되면 통합적인 관리하기가 매우 힘들어집니다.
물론 이렇게 OS배포폰 관리, yum repo 관리, rpm 관리 및 업데이트를 하기 때문에 부담감은 있지만 그보다는 일관된 관리를 통한 편리함이 더 큰 것 같습니다.

yum repo 도 kickstart 와 마찬가지로 global cache 를 이용하며 acl을 통하여 접근제한을 하고 있습니다. global cache 를 통해 빠른 속도를 보장하고 acl을 통해 보안을 관리하는 것입니다. (rpm 의 경우는 centos 등 처럼 gpg 키를 이용하여 sign 을 해서 관리합니다)

- 정책적으로 각종 애플리케이션 배포는 자체 yum repo만 이용하고 최대한 rpm 으로 관리
- 정책적으로 표준 rpm 빌드 가이드라인에 따라 rpm 생성

 

Labels
  • No labels