우리는 몇 (5 정도 정도) 상자에서 실행되는 응용 프로그램이 있습니다. 하드웨어는 모든 머신에서 동일하며 이상적으로는 소프트웨어도 마찬가지입니다. 나는 지금까지 손으로 그들을 관리해 왔으며 더 이상 (정적 IP 주소, 모든 필요한 서비스 비활성화, 필요한 패키지 설치 ...) 원하지 않습니다. 다음 옵션의 장단점을 조정할 수 있습니까?

1 : 모든 상자에 centos를 개별적으로 설치하고 chef / cfengine / puppet을 사용하여 구성을 관리하십시오. 응용 프로그램 중 하나를 사용하는 방법을 배우기위한 변명을 원했기 때문에 이것은 좋을 것입니다. 그러나 이것이 실제로 가장 좋은 해결책인지는 모르겠습니다.

2 : 하나의 상자를 완벽하게 만들고 이미지를 만듭니다. PXE를 통해 이미지를 제공하고 수정을 원할 때마다 새 이미지에서 상자를 재부팅하면됩니다. 클러스터 사용자는 일반적으로 / etc / sysconfig / network-scripts / ifcfg * 파일에 mac 주소를 갖는 것과 같은 작업을 어떻게 처리합니까? 우리는 infiniband도 사용하며, hwaddr이 잘못되면 시작을 거부합니다. 부팅시 올바르게 생성 할 수 있습니까?

PXE 솔루션을 기대하고 있지만 munin 또는 nagios로 모니터링하는 것이 조금 더 복잡 할 것이라고 생각합니다. 이런 종류의 문제에 경험이 있습니까?

모든 서버에는 SSD가 있으며 빠르고 강력합니다.

고마워, 매트

클러스터는 내 것과 같은 OLTP보다 HPC 클러스터처럼 들리지만 사용중인 설정도 효과가 있다고 생각합니다. 나는 그것을 "mpdehaan trifecta"라고 부릅니다. 왜냐하면 관련된 세 가지 도구를 쓰거나 관리하는 사람의 귀찮은 일이기 때문입니다.

1.) 기본 빌드 프로비저닝을위한 Cobbler . Cobbler는 킥 스타트, pxe, yum-repo, dhcp, dns 등 시스템의 교차점이되는 프로젝트입니다. 킥 스타트 설정을 시작하고 실행하는 가장 쉬운 방법이며 필요에 따라 다른 기능으로 확장 할 수 있습니다.

2.) 구성 관리를위한 꼭두각시 . 이상적으로 cobbler 내장 호스트는 시작시 꼭두각시 서버로 전화를 걸기에 충분히 알 수 있는 매우 베어 구성입니다 . 그러면 Puppet은 구성 설정을 적용하고 환경 전체에서 지속적으로 일관성을 유지합니다.

3.) 여러 기계에 병렬로 임시 명령을위한 기능 . 예를 들어 "코드의 새 svn 체크 아웃을 배치하고 아파치를 다시 시작하십시오". func를 사용하여 cluster-ssh와 같은 서버 그룹에서 동일한 bash 명령을 호출하는 것은 매우 쉽습니다. 정말로 들어가고 싶다면 정말 간단한 파이썬으로 모듈을 작성할 수 있습니다.

이 세 가지 도구 모두 프리 노드에 도움이되는 훌륭한 위키 및 활성 irc 채널이 있습니다.

개요

어떤면에서는 여기에 두 가지 질문이 있습니다.

• 표준 서버를 구축하고 유지 관리하는 방법
• 표준 구성을 유지 관리하고 나중에 변경하려면 어떻게합니까?

나는 그 두 가지를 개별적으로 다루기 위해 대답을 아래에서 나누었지만 매우 밀접한 관련이 있습니다. 변경 관리와 같은 모범 사례가 아닌 여기에서 기술 솔루션을 다루고 있습니다.

이것이 귀하의 질문의 범위를 다루지 않는 경우 명확하게 설명해 주시면 기꺼이 도와 드리겠습니다. 이것은 잘 운영되는 기술 인프라에 중요한 기초입니다.

서버 구축

나는 유닉스 세계에서 이미지를 좋아하지 않는다. 그것은 Windows 스타일의 접근 방식입니다. 일부 Windows 사용자조차도 현재 표준 빌드를위한 스크립트에 초점을 맞추고있는 것 같습니다.

RHEL 세계에서 위성이 다소 인기를 얻고있는 것 같습니다. Spacewalk는 오픈 소스입니다. 이를 사용하려면 RHEL 접근 방식을 완전히 구입해야합니다. 이것은 서버 구축 및 구성 관리의 역할을합니다.

이상적으로는 필요한 모든 소프트웨어의 파일 서버에 로컬 미러 및 리포지토리를 설정하려고합니다.

먼저 RHEL / CentOS의 킥 스타트와 같은 배포 빌드 자동화를 활용하십시오. 킥 스타트는 필요에 따라 변형 된 기준선이됩니다. 킥 스타트 빌드는 PXE 서버에서 시작할 수 있습니다.

빌드의 고급 부분과 킥 스타트 파일에 적합하지 않은 것을 위해, 자신 만의 스크립트를 작성할 수 있습니다. 그러나 꼭두각시 나 cfengine이 사용자 정의 스크립트 대신 잘 작동한다는 것을 알 수 있습니다. 사용자 정의 스크립트가 가장 유연하고 단일 접근 방식에만 국한되지 않는다는 것을 알았습니다.

자체 스크립트를 작성하기로 선택한 경우 범용 구성을위한 핵심 스크립트를 권장합니다. 이것은 보안 구성, 강화 및 모든 빌드에 적용되는 모든 것입니다. 그런 다음 서버 역할을 마무리하는 마지막 스크립트입니다. 예를 들어, 웹 서버 또는 데이터베이스 서버입니다.

표준 유지

설명하는 내용은 구성 유지 관리에도 해당됩니다. 빌드 표준, 소프트웨어 업데이트 및 기타 사항은 빌드와 관련되어 있지만 많은 방법으로 분리되어 있습니다.

가장 중요한 서버 역할을위한 자체 소스 기반 빌드를 작성하는 대신 시스템 패키지를 사용하기로 선택한 경우 기본 시스템 유틸리티를 사용하여 많은 부분을 유지할 수 있습니다. for서버 목록에 대해 루프 를 실행 하고을 실행하는 간단한 스크립트 일 수 있습니다 yum -y update package.

구성 관리의 경우 꼭두각시, cfengine 및 기타 구성 관리 유틸리티가 사용됩니다. 이것들은 매우 유용한 유틸리티이며 스크립트를 처음부터 작성하지 않고도 필요한 기초를 제공합니다.

서버의 구성 표준을 업데이트 할 때는이를 표준 서버 빌드로 다시 채우는 것이 중요합니다.

최근에 $ WORK에서 중앙 집중식 빌드 / 프로비저닝 및 구성 관리 시스템을 출시하기위한 대규모 프로젝트를 완료했습니다. 우리는 CentOS를 운영하고 있습니다.

제가 정말로 좋아하는 제 디자인은 간단하지만 효과적인 웹 UI를 통해 모든 것을 하나로 묶는 맞춤형 PHP 스크립트를 사용하여 사실상 한 번의 클릭 (웹 GUI 페이지 하나) 빌드 프로세스를 제공합니다.

일반적인 이론은 다음과 같습니다.

1. 하나의 통합 된 미니멀리스트 킥 스타트 파일 (x86 및 x86-64 용 파일이지만 최소한의 패키지 선택만으로도 거의 동일한 파일)에서 모든 설치를 수행하십시오.
2. KickStat 사후 설치 스크립트 부트 스트랩 Puppet.
3. Puppet은 모든 노드 / 호스트 별 구성, 패키지 설치 등을 적용합니다.

나는 이미지가 일을하는 유닉스 방식이 아니라는 것에 동의합니다 ... 스크립트 / 자동화 된 설치 및 구성이 간단하지 않은 Windows 세계에 더 적합합니다.

Puppet을 비용에 맞는 다른 구성 관리 시스템으로 대체 할 수 있지만 Puppet의 선언적 특성과 수렴 개념을 좋아합니다.

이 시스템은 여러 가지 이점을 제공합니다.

• Puppet은 일반 기본 설치 이후의 모든 것을 처리하므로 필요한 모든 패키지 및 구성이 한 곳에 있습니다.
• Puppet 매니페스트는 하위 수준 설명서의 추가 소스로 사용됩니다.
• Puppet을 사용하는 한 (즉, 로컬 구성을 변경하거나 Puppet에 다시 병합하지 않는 한) 머신의 복제본을 만드는 것은 쉽지 않습니다.
• 모든 호스트는 공통 기반으로 구축되므로 기본 (KickStart) 패키지 세트를 사용하여 하드웨어 또는 VM을 사전 설치 한 다음 필요에 따라 클래스를 추가하여 기능 노드로 전환 할 수 있습니다.
• Puppet을 사용하면 프로덕션 또는 개발을 위해 호스트에 "태깅"태그를 지정할 수 있으므로 호스트의 개발 / 테스트 복사본을 작성하고 패키지를 업그레이드하거나 필요에 따라 구성을 변경하고 테스트 한 다음 프로덕션으로 다시 병합하는 것이 매우 쉽습니다.

pxe 경로를 내려 가면 살펴보십시오.

http://etherboot.org/wiki/index.php

Gpxe는 부팅 대상에 더 많은 유연성을 제공합니다. aoe 블레이드를 부팅하는 것은 매우 쉽고 원격 http 서버에서 커널을 부팅하는 것과 같은 것은 없습니다 !!!!!!!!!! :-).

어떤 서버 가동 시간이 필요합니까?

항상 보안 패치 및 소프트웨어 업그레이드를 적용해야하므로 완벽한 이미지를 만드는 것은 불가능합니다. 인터넷에 연결되어 있다면 패치를 무시할 수 없습니다.

pxe 측에는 클러스터의 파일 I / O에 따라 몇 가지 옵션이 있습니다. 커널을 부팅하고 aoe 또는 iscsi를 통해 원격으로 디스크를 마운트하십시오.

쓰기 이미지에 복사하여 매우 영리한 작업을 수행 할 수도 있습니다. 업그레이드 및 문제가 될 수있는 변경 사항을 롤백하는 데 유용합니다.

또한 클러스터 된 nfs 솔루션을 사용하여 nfs root를 사용하여 성공했습니다. 클라이언트 주소에 따라 제공 할 다른 파일을 지정할 수 있습니다.

다시 한 번, 응용 프로그램이 nfs를 실행하는 것을 좋아하는지 확인해야합니다. 모든 작업에 적합하지는 않습니다.

클러스터 된 nfs 서버는 192.168.0.1:/etc/hostname을 포함 할 수 있습니다. 192.168.0.2:/etc/hostname

따라서 모든 클라이언트는 동일한 파일을 참조하지만 클라이언트와 관련된 파일을 제공받습니다. 꽤 인상적인 물건이지만 간단하지 않습니다!

이 모든 것이 네트워크 스토리지에서 파일 시스템을 중앙 집중화하면 더 빠른 롤아웃 시간을 제공합니다. 네트워크를 통해 원격 디스크에 운영 체제를 이미징하는 데 시간이 걸립니다 !!!!

이러한 솔루션을 사용하는 경우 잘 설계되고 내결함성이있는 네트워크 계층이 있고 nfs / SAN 서버가 잘 설계되어 있고 안전한지 확인하십시오!

NFS / SAN 연결이 끊어지면 서버 상태가 나빠질 수 있습니다. :-(

부트 프로세스를 제어하기 위해 tftp / pxe에 대한 일부 스크립트를 작성하는 것은 매우 쉽습니다.

실제로 클러스터하려는 것을 더 많이 알고 있다면 아마도 더 적합한 솔루션을 생각할 수 있습니다.