"기존 프로덕션 EL5 서버를 EL6으로 업그레이드 할 수 있습니까?"

완전히 다른 환경을 가진 두 고객의 간단한 요청으로 인해 일반적인 모범 사례는 "그렇습니다. 그러나 모든 시스템 의 조정 된 재구성 "이 필요합니다 ...

두 고객 모두 시스템을 완전히 재 구축하는 것이 다운 타임 및 리소스 이유로 허용 할 수없는 옵션이라고 생각합니다 ... 시스템을 완전히 다시 설치해야하는 이유에 대한 질문을 받았을 때 "그렇습니다. ... "

구성 관리 ( " 모든 항목을 항상 적용 " 하는 것이 항상 적용되는 것은 아님 ) 또는 클라이언트가 더 나은 계획을 세우는 방법에 대한 응답을 유도하려고 하지 않습니다 . 이는 실제 생산 환경에서 성장하고 번성 한 환경의 실제 예이지만 다음 버전의 OS로 이동하기위한 확실한 경로는 보이지 않습니다.

환경 A : Java 웹 응용 프로그램 스택, 소프트웨어로드 밸런서 및 Postgres 데이터베이스를 실행하는 40 개의 Red Hat Enterprise Linux 5.4 및 5.5 웹, 데이터베이스 서버 및 메일 서버
가있는 비영리 조직 . 모든 시스템은 각각 HA, DRS 등이있는 서로 다른 위치에있는 2 개의 VMWare vSphere 클러스터에서 가상화됩니다.

환경 B : 생산 거래 운영을 실행하는 여러 코 로케이션 시설에 200 x CentOS 5.x 시스템을
갖춘 고주파 금융 거래 회사로서 사내 개발 및 백 오피스 기능을 지원합니다. 거래 서버는 베어 메탈 상품 서버 하드웨어에서 실행됩니다. 그들은 많은 한 , 메시징 대기 시간을 낮은 자리에 바인딩 및 드라이버 개조하면 되겠 인터럽트. 일부에는 사용자 정의 및 / 또는 실시간 커널이 있습니다. 개발자 워크 스테이션도 비슷한 버전의 CentOS를 실행하고 있습니다.sysctl.confrtctl

두 경우 모두 환경이 그대로 실행됩니다. 업그레이드하고자하는 바는 EL6에서 사용 가능한 최신 응용 프로그램이나 기능이 필요하다는 데 있습니다.

• 비영리 회사의 경우 아파치, 커널 및 개발자를 행복하게 해줄 것들에 묶여 있습니다.
• 트레이딩 회사에서는 커널, 네트워킹 스택 및 GLIBC의 일부 개선 사항에 대해 개발자를 기쁘게합니다.

둘 다 운영 체제를 크게 변경 하지 않으면 쉽게 패키징하거나 업데이트 할 수없는 것들입니다 .

시스템 엔지니어로서 Red Hat은 메이저 버전 릴리스 사이를 이동할 때 전체 재 구축을 권장합니다. 깔끔한 시작으로 리팩터링하고 구성에주의를 기울여야합니다.

고객의 비즈니스 요구에 민감하기 때문에 이것이 왜 그렇게 어려운 작업 인지 궁금합니다 . RPM 패키징 시스템은 전체 업그레이드를 처리 할 수있는 능력 이상이지만, /boot더 많은 공간이 필요하고, 새로운 기본 파일 시스템이 필요하고, RPM이 중간 업그레이드, 더 이상 사용되지 않거나 사용되지 않는 패키지를 깨뜨릴 수 있습니다 ...

여기에 답이 무엇입니까? 다른 배포판 (.deb 기반, Arch 및 Gentoo)에는이 기능 또는 더 나은 경로가있는 것 같습니다. 이 작업을 올바른 방식으로 수행하기위한 다운 타임이 있다고 가정 해 보겠습니다 .

• EL7이 릴리스되고 안정화 될 때 동일한 문제를 피하기 위해 이러한 클라이언트는 어떻게해야합니까?
• 아니면 사람들이 몇 년마다 완전 재건을 위해 사임해야하는 경우입니까?
• Enterprise Linux가 발전함에 따라 이것은 더 나빠진 것 같습니다 ... 아니면 그냥 상상하고 있습니까?
• 이로 인해 누군가 Red Hat 및 파생 운영 체제를 사용하지 못하게 되었습니까?

구성 관리 각도가 있다고 생각하지만 대부분의 Puppet 설치는 고도로 사용자 정의 된 응용 프로그램 서버가있는 환경으로 잘 변환되지 않습니다 ( 환경 B 에는 ifconfig출력이 다음과 같은 단일 서버가있을 수 있음 ). 하지만 조직이 RHEL 주요 버전 충돌을 극복하는 데 구성 관리를 사용하는 방법에 대한 제안을 듣는 데 흥미가 있습니다.

(저자 참고 :이 답변은 RHEL 6 및 이전 버전을 나타냅니다. 이제 RHEL 7은 RHEL 6에서 완전히 지원되는 업그레이드 경로를 제공합니다. 자세한 내용은 마지막 부분에 있습니다.)

시작하려면 전체 업그레이드를 수행하는 두 가지 방법 이 있습니다 .

1. 설치 DVD를 드롭하거나 (또는 ​​iLO / iDRAC를 통해 DVD 이미지 사용) 부팅 한 다음 업그레이드를 선택하십시오 (예 :) linux upgradeany.
2. redhat-releaseRPM을 수동으로 업데이트하고 실행 yum distro-sync(간단히 단순화 됨) 한 다음 재부팅하십시오.

방법 1은 지원되지 않습니다. 방법 2는 Real Cowboys입니다. 권장되는 새로운 설치 외에도 두 가지를 모두 수행했습니다 ...

지원이 필요합니까?

지원 은 우리 세계에서 두 가지 보완적인 의미를 갖습니다. 첫 번째는 제품에 특정 기능이 있다는 것입니다 (예 : "Postfix supports SMTP"). 두 번째는 공급 업체가 이에 대해 이야기한다는 것입니다. 어떤 정의의 의미가 항상 문맥에서 명확하지는 않습니다.

과제를 완수하려면 분명히 첫 번째 의미에서 지원이 필요합니다. 공급 업체 지원은 문제를 해결하고 존재하거나 개선해야 할 기능에 대한 공급 업체 피드백을 제공하는 데 도움을줍니다. 많은 사이트는 공급 업체보다 더 빠르고 저렴하게 발생할 수있는 문제를 해결하기위한 사내 전문 지식을 보유한 공급 업체 지원에 대한 대가를 지불합니다. 공급 업체 지원 구매 여부는 궁극적으로 비즈니스 결정으로 결정해야합니다 (또는 경영진에게 조언).

전체 업그레이드는 어떻습니까?

이다 레드햇은 그것에 대해 말씀 :

Red Hat은 Red Hat Enterprise Linux의 주요 버전 간 전체 업그레이드를 지원하지 않습니다. 메이저 버전은 정수 버전 변경으로 표시됩니다. 예를 들어, Red Hat Enterprise Linux 5 및 Red Hat Enterprise Linux 6은 모두 Red Hat Enterprise Linux의 주요 버전입니다.

주요 릴리스의 전체 업그레이드는 모든 시스템 설정, 서비스 또는 사용자 정의 구성을 유지하지 않습니다. 따라서, Red Hat은 하나의 메이저 버전에서 다른 메이저 버전으로 업그레이드 할 때 새로 설치할 것을 적극 권장합니다.

그들은 더 경고합니다.

그러나 시스템 업그레이드를 선택하기 전에 다음 제한 사항에 유의하십시오.

• 다양한 구성 파일 형식 또는 레이아웃의 변경으로 인해 업그레이드를 수행 한 후 개별 패키지 구성 파일이 작동하거나 작동하지 않을 수 있습니다.
• Red Hat의 계층 제품 (예 : Cluster Suite) 중 하나가 설치되어있는 경우 Red Hat Enterprise Linux 업그레이드가 완료된 후 수동으로 업그레이드해야합니다.
• 업그레이드 후 타사 또는 ISV 응용 프로그램이 올바르게 작동하지 않을 수 있습니다.

물론, 실제로 원하는 경우를 대비하여 방법 1을 통해 전체 업그레이드를 수행하는 방법을 설명합니다. 이 기능이 존재하고 Red Hat은 개발 시간을 제공하므로 해당 기능이 존재하도록 지원됩니다. 그러나 문제가 발생하면 Red Hat은 새로 설치하라는 메시지를 표시합니다. 업그레이드로 인해 중단 된 사항에 대해서는 공급 업체 지원을 제공하지 않습니다.

기록 상으로는, 실제로 스스로 해결할 수없는 RHEL / CentOS 또는 Fedora 시스템의 전체 업그레이드에 문제가 없었습니다. 일반적인 문제는 이름이 바뀐 패키지, 타사 리포지토리 및 패키지의 i386과 x86_64 아키텍처간에 간헐적 인 버전 불일치로 인해 발생합니다. 설치 프로그램이 이것들을 처리하는 데 조금 더 낫습니다 yum.

어떻게 업그레이드해야합니까?

나는 일반적으로 사람들에게 RHEL 시스템을 하나의 주요 버전에서 다음 버전으로 업데이트하기 위해 3-4 년마다 유지 관리 기간을 계획 해야한다고 경고 합니다. 업그레이드는 일반적으로 순조롭게 진행되지만 예기치 않은 상황이 발생할 수 있습니다.

두 환경 모두에서 전체 업그레이드가 작동 할 것으로 예상되지만 먼저 철저히 테스트하는 것이 좋습니다. P2V는 서버의 대표적인 샘플이며 가상 시스템에서 전체 업그레이드를 통해 실행되어 어떤 문제가 발생하는지 확인합니다. 그런 다음 어떻게 될지에 대한 더 나은 지식을 바탕으로 실제 프로덕션 업그레이드를 계획 할 수 있습니다.

여기에있는 대규모 배포의 경우 Limoncelli의 "일대 다"접근 방식을 사용하십시오. 한 대의 기계를 업그레이드하고, 어떤 문제가 발생하는지 확인하고, 해결 한 다음 작은 기계 배치를 업그레이드 할 때 배운 교훈을 사용하고, 배운 교훈을 반복 한 다음, 모든 꼬임이 해결되었다고 생각되면 큰 배치를 업그레이드하십시오.

이와 같은 시점에 응용 프로그램 배포 프로세스를 자세히 살펴 보는 것도 좋습니다. 자동화가 충분하지 않아 단일 명령으로 실행할 수 있고 앱이 올바르게 배포되는지 합리적으로 확신한다면 개발자가 해당 작업을 수행해야합니다. 이러한 배포 프로세스를 사용하면 최신 버전의 EL을 새로 설치 한 다음 배포 할 수 있습니다.

분배 분배가 도움이됩니까?

데비안 기반 배포판에는 지원되는 전체 업그레이드 방법이 있으며 대부분 작동하지만 문제의 영향을받지는 않습니다. 예를 들어 지원되는 방법을 통해 Ubuntu 10.04 LTS에서 12.04 LTS로 업그레이드 하는 사람들에게는 많은 일이 발생했습니다 . 데비안이나 Canonical이이 기능을 "지원"하는데 충분한 시간을 투자하고 있다는 것은 확실하지 않습니다. 그리고 누군가가 당신의 손을 잡고 싶다면 실제로이 배포판에 대한 공급 업체 지원을 구매해야합니다. 따라서 그러한 배포로 전환하면 많은 이점을 얻을 수 있을지 의문입니다.

젠투 또는 아치와 같은 롤링 배포판으로 전환하면 얻을 수 있습니다. 그러나 이것은 또한 당신이 문제에 면역되지는 않습니다. 그것은 단지 계획된 배포 업그레이드 시간에 한 번에 서버가 아닌 서버 수명 동안 지속적으로 업그레이드 문제를 처리해야한다는 것을 의미합니다. 또한 지원을 제공 할 공급 업체가 없습니다.

미래에는 어떤 것이 있습니까?

Fedora Project는 전체 업그레이드를 개선하기위한 도구를 개발 중입니다. 그들은 preupgrade버려진 도구를 가지고 있었고 Fedora 18로 시작하는 fedup 이라는 새로운 도구로 대체되었습니다 . 이것은 RHEL7에 추가되었으며 현재 전체 업그레이드는 최소한 RHEL 6에서 RHEL 7로 완전히 지원 됩니다. 내 자신의 경험에서 나는 fedup여전히 약간의 꼬임이 있지만 매우 유용한 도구 가되고 있다고 말할 수 있습니다 .

CentOS는 롤링 릴리스 유형의 저장소를 실험하고 있지만 부 버전 (예 : 6.3-6.4)에만 적용됩니다.

당신의 마지막 단락에 대한 나의 테이크 :

구성 관리 각도가 있다고 생각하지만 대부분의 Puppet 설치는 고도로 사용자 정의 된 응용 프로그램 서버가있는 환경으로 잘 변환되지 않습니다 (환경 B에는 ifconfig 출력이 다음과 같은 단일 서버가있을 수 있음). 하지만 조직이 RHEL 주요 버전 충돌을 극복하는 데 구성 관리를 사용하는 방법에 대한 제안을 듣는 데 흥미가 있습니다.

구성 관리 시스템, 특히 환경 B와 관련하여 실제 구성 관리 시스템의 가치는 서비스를 실행하는 서버와 독립적으로 서비스를 구성 할 수있는 도구를 제공한다는 것입니다. CMS를 사용하여 기존 서비스를 만들지 않은 경우 서비스를 다시 만드는 데 큰 도움이되지 않을 것입니다.

나는 이것이 당신의 즉각적인 문제를 해결하지 못한다는 것을 알고 있지만, 그것은 서비스가 아닌 서버의 관점에서 생각하는 조직에서 나옵니다. 서비스 중심 사고에서 서비스가 계속 작동하는 한 개별 서버의 성격을 유지할 필요는 없습니다. CMS를 훈련 된 방식으로 사용하여 전체 서비스를 구축하는 경우 해당 시스템의 모든 성격이 CMS에 의해 작성되므로 해당 서비스를 다른 시스템으로 옮기는 것이 비교적 간단해야합니다.

추신 : 나는이 컨텍스트에서 ifconfig 출력에 대해 중요한 것이 확실하지 않습니다. 구성 파일과 일부 스크립트 (부팅시 존재하지 않을 것입니다)에 의해 생성되며 필요한 경우 CMS에서 관리 할 수 ​​있습니다.