ClickCease 지원되지 않는 OS를 업그레이드하는 방법: 심층 체크리스트 - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

지원되지 않는 OS를 업그레이드하는 방법: 심층 체크리스트

2021년 3월 25일 - 2021 TuxCare 홍보팀

지원되지 않는 OS를 업그레이드하는 방법: 심층 체크리스트OS 업데이트는 사소한 작업처럼 보입니다. 시스템 관리자가 본능적으로 수행할 수 있는 작업 유형입니다. 하지만 실제로 이 작업의 전체 범위를 고려해 본 적이 있나요? 이 작업을 성공적이고 안전하며 예측 가능하게 수행하기 위해 함께 엮어야 하는 모든 다양한 스레드를 생각해 보셨나요? 운영 체제가 오래되었을 뿐만 아니라 다음과 같은 문제가 있다면 어떨까요? 더 이상 지원되지 않음?


운영 체제에 대한 공급업체의 공식 지원은 항상 기간이 제한되어 있습니다. 공급업체가 소수의 사용자를 무한정 지원할 것이라고 기대하는 사람은 아무도 없습니다. 운영 체제(OS)의 주요 버전은 대략 10년 정도 지원되는 것이 일반적입니다.

OS가 Lifecycle 종료(EOL)되면 공식 지원이 중단됩니다. 즉, 보안 및 유지 보수 패치가 제공되지 않으며 문제가 발생할 경우 표준 지원 옵션이 제공되지 않습니다. 이는 매우 위험한 상황이며, 일반 소비자부터 기업까지 모든 사용자는 일반적으로 제때에 최신 버전으로 업그레이드합니다. 결국 사용자도 최신 기능을 원합니다.

그러나 엔터프라이즈 사용자의 경우 OS 업그레이드 프로젝트는 가볍게 시작할 수 있는 일이 아니며, 실제로 어떤 작업이 필요한지 과소평가하기 쉽습니다.

이 가이드에서는 더 이상 지원되지 않는 OS를 사용할 때의 위험성을 간략히 설명하고 운영 연속성을 위협하지 않는 안전한 마이그레이션을 위한 3단계의 주요 단계를 제안합니다. 또한 지금 당장 업그레이드를 진행할 수 없는 경우를 대비하여 몇 가지 대안을 제시합니다.

콘텐츠

 

Lifecycle 종료 및 업그레이드하지 않을 경우의 위험에 대한 이해

Lifecycle 종료 및 업그레이드하지 않을 경우의 위험에 대한 이해

 

운영 체제를 포함한 모든 주요 소프트웨어는 시간이 지남에 따라 발전합니다. 몇 년마다 새로운 기능을 제공하는 주요 새 릴리스가 시장에 출시되고, 사용자는 새 릴리스를 활용하기 위해 업그레이드합니다. 이는 기술 발전의 본질입니다.

공급업체는 사용자가 최신 버전으로 마이그레이션할 수 있는 시간을 제공하기 위해 일정 시점까지 이전 버전을 유지 보수할 것을 약속합니다. 이 지원 기간은 종종 몇 개의 소프트웨어 버전에 대해 과거까지 연장되며, 대형 벤더는 지원 종료 시기를 자세히 설명하는 로드맵을 게시합니다. 이는 단계적으로 진행되며, 표준 지원 채널이 사실상 폐쇄될 때까지 지원이 축소됩니다.

 

 

 

실제로 Lifecycle 종료는 무엇을 의미하나요?

실제로 Lifecycle 종료는 무엇을 의미하나요?

 

표준 지원에는 두 가지 계층이 포함됩니다. 첫째, 소프트웨어 공급업체는 소프트웨어가 출시된 후 발견된 모든 문제를 해결하기 위해 노력합니다. 여기에는 기능상의 결함, 성능 개선 또는 보안 취약성에 대한 패치가 포함될 수 있습니다.

다음으로, 공급업체는 일반적으로 사용자가 구매한 소프트웨어에 문제가 발생할 경우 이메일, 채팅 또는 업그레이드된 지원 환경 등 사용자가 활용할 수 있는 지원 채널을 제공합니다.

공급업체는 지원 일정을 게시합니다. 예를 들어 성능 문제를 포함한 모든 세부 사항을 포괄하는 완전하고 포괄적인 지원은 3년 동안 지속될 수 있습니다. 일부 지원 요소는 향후 몇 년에 걸쳐 제거될 수 있으며, 예를 들어 출시 후 8년이 지나면 공급업체는 중요한 패치만 게시할 수 있습니다.

결국 모든 지원이 중단되고 소프트웨어는 공식적으로 Lifecycle이 종료됩니다.

 

 

 

어떤 위험이 있나요?

어떤 위험이 있나요?

 

Lifecycle이 다한 소프트웨어는 정적입니다. 소프트웨어 공급업체는 더 이상 소프트웨어에 대한 변경 사항을 게시하지 않습니다. 많은 워크로드에 안정적인 지원 운영 체제가 필요하기 때문에 언뜻 보기에는 좋은 일로 보일 수 있습니다. 하지만 지원되지 않는 정적 소프트웨어는 다양한 문제를 일으킬 수 있습니다:

  • 보안 취약성. 소프트웨어 보안은 유동적인 환경입니다. 널리 사용되는 주요 운영 체제의 경우 공식 지원이 종료된 후에도 새로운 취약점이 발견될 가능성이 거의 보장됩니다. 그러나 공급업체가 더 이상 새로운 취약점에 대한 패치를 릴리스하지 않으면 이러한 보안 허점은 지속될 것이며, 업그레이드하지 않은 사용자는 운영에 심각한 취약점을 겪을 수 있습니다.
  • 진입점. 지원되지 않는 OS를 업그레이드할지 여부를 결정할 때 흔히 범하는 오류 중 하나는 해당 OS가 보조 시스템이나 중요하지 않은 시스템에서 실행되고 있으므로 실제 위험이 없다고 가정하는 것입니다. 실제로는 지원되지 않는 OS의 취약점으로 인해 공격자가 네트워크에 침입하여 더 중요한 시스템으로 공격을 확대할 수 있는 기회를 제공할 수 있습니다.
  • 성능, 안정성 및 호환성. 지원되지 않는 OS는 성능 조정 및 개선이 이루어지지 않으며, 새로운 안정성 문제가 발생해도 공급업체에서 더 이상 수정하지 않습니다. 마찬가지로 지원되지 않는 소프트웨어는 결국 불가피하게 발전한 나머지 기술 세계와의 호환성을 유지하기 위해 비용이 많이 들고 성능이 좋지 않은 해결 방법을 사용해야 합니다.
  • 규제 및 규정 준수 문제. 지원되지 않는 소프트웨어 실행의 위험은 널리 알려져 있어 전 세계 정부 및 기관에서 규정 준수 프레임워크를 사용하여 조직이 지원되고 패치된 소프트웨어를 사용하도록 강제하고 있습니다. 또한 대기업은 다양한 이해관계자에게 책임을 져야 하므로 지원되지 않는 소프트웨어를 사용하면 책임감이 부족하다는 것을 보여줄 수 있습니다.
  • 디지털 트랜스포메이션 차단. 지원되지 않는 소프트웨어가 광범위하게 사용되면 결국 조직 내부의 기술 발전을 가로막게 됩니다. 지원되지 않는 레거시 소프트웨어가 혁신 프로그램의 구현을 방해하기 때문에 혁신이 지연되거나 더디게 진행됩니다.
  • 고객과 직원의 불만. 지원되지 않는 운영 체제는 또한 오래된 기능 세트를 제공할 가능성이 높습니다. 즉, 고객은 조직의 느린 응답에 실망하고, 직원은 지루하고 응답이 없는 시스템으로 인해 업무에 지장을 받아 사기가 저하될 수 있습니다.

 

Lifecycle이 종료된 OS 버전에 의존하면 비용이 많이 드는 치명적인 보안 침해부터 운영 비용 증가, 수익 감소, 매출 성장률 저하 등 다양한 수익에 영향을 미칠 수 있습니다.

 

 

실제적이고 현존하는 위험

실제적이고 현존하는 위험

 

잠시 멈춰서 생각해 볼 필요가 있습니다. 대부분의 기업은 비즈니스를 지속하기 위해 기술에 크게 의존하고 있습니다. OS와 같은 소프트웨어가 더 이상 공식적으로 지원되지 않으면 문제가 발생했을 때 의지할 곳이 없어지고, 지원되지 않는 운영 체제인지 아니면 애플리케이션이 문제를 일으켰는지 파악하기 어려울 수 있습니다.

더 심각한 문제는 지원되지 않는 운영 체제가 보안 공격에 노출되어 언론에 보도됨으로써 조직이 재정적으로나 평판 측면에서 상당한 손실을 입을 수 있다는 것입니다.

어느 쪽이든 지원되지 않는 운영 체제에 의존하면 비즈니스가 심각한 위험에 처할 수 있습니다.

 

 

3단계 마이그레이션 체크리스트

3단계 마이그레이션 체크리스트

 

새 운영 체제로 마이그레이션하는 것이 가장 좋은 방법이지만, 마이그레이션이 복잡하다고 인식되거나 마이그레이션의 위험을 최소화하기 위해 취해야 할 단계에 대한 불확실성 때문에 마이그레이션을 연기하는 경우가 많습니다.

마이그레이션으로 인해 기한을 놓치는 것부터 비용이 많이 드는 서비스 다운타임에 이르기까지 피할 수 있는 문제가 발생하는 경우도 있습니다. 이 체크리스트에서는 마이그레이션 성공 확률을 극대화하고 마이그레이션 시 장애물이 발생할 경우 복구할 수 있는 경로를 제공하기 위해 조직이 취해야 할 주요 단계를 다루고자 합니다.

아래의 많은 사항이 소프트웨어 마이그레이션에 전반적으로 적용되지만, 여기서는 OS 마이그레이션에 중점을 둡니다. 세 번째 단계인 페일백이 필요하지 않을 수도 있지만, 필요할 수도 있다는 가정 하에 계획해야 합니다.

 

1: 마이그레이션 준비

1: 마이그레이션 준비

 

말할 필요도 없이 준비가 핵심입니다. 여기에는 테스트, 마이그레이션을 수행할 창 찾기, 마이그레이션을 수행하는 데 필요한 리소스가 조직에 준비되어 있는지 확인하는 것이 포함됩니다. 이것이 마이그레이션 준비의 핵심 단계라고 생각합니다:

 

 

철저한 테스트 및 테스트

철저한 테스트 및 테스트

 

마이그레이션을 시도하기 전에 테스트 환경 내에서 새 운영 체제에서 워크로드를 실행할 수 있는지 테스트해야 합니다. 즉, 새 운영 체제를 임시 환경에서 설정하고 애플리케이션을 실행하여 구성 및 종속성이 완벽하게 실행되는지 확인한 후 새 OS의 구성을 프로덕션 환경으로 푸시해야 합니다.

테스트가 첫 번째 단계가 되어야 합니다. 테스트 환경 내에서 워크로드가 새 OS 버전에서 완벽하게 작동하는지 확인할 수 없는 경우, 문제가 해결될 때까지 마이그레이션 프로세스를 일시 중지해야 합니다. 워크로드를 철저히 로드 테스트하기 전까지는 마이그레이션 기간을 설정하고 리소스를 예약해 두지 않는 것이 좋습니다. 시스템의 실제 워크로드를 재현 가능한 방식으로 처리하지 않고 간단한 기본 테스트만 건너뛰거나 수행하면 전체 업그레이드의 성공 여부는 실제 기술보다는 순전히 운에 달려 있습니다.

 

 

유지 보수 기간 선택 및 커뮤니케이션

유지 보수 기간 선택 및 커뮤니케이션

 

마이그레이션은 혼란을 야기할 수 있으므로 모든 이해관계자에게 유지 보수 기간을 알려 마이그레이션에 충분한 시간을 확보해야 합니다. 이 기간의 길이를 결정할 때는 다음 요소를 고려하세요:

  • 백업 시간 및 데이터 복사 시간
  • 실시간 테스트 및 중요한 이해 관계자에게 모든 것이 의도한 대로 작동하는지 테스트할 수 있는 기회 제공
  • 오버런에 대한 버퍼 - 스크립트대로 진행되지 않을 때를 대비해 최소 10%에서 15%의 버퍼를 확보하세요.

최소한 백업에서 시스템을 신속하게 복구하거나 장애가 발생한 경우 이전 하드웨어를 다시 설치하는 데 걸리는 시간을 고려해야 합니다. 장애 복구에 대해서는 이후 섹션에서 자세히 설명합니다.

 

 

드라이버 지원 확인

드라이버 지원 확인

 

대부분의 경우 새 OS는 이미 설치되어 있는 하드웨어와 구형 하드웨어에서 실행됩니다. 하지만 새 하드웨어에 새 OS를 설치하는 경우에도 드라이버 지원이 문제가 되지 않는지 다시 한 번 확인해야 합니다.

예를 들어, 하드웨어 공급업체와의 지원 계약이 유효한지 확인하여 필요한 경우 공급업체의 지원을 받을 수 있도록 하세요. 지원 계약이 만료되었거나 미지급되었다는 불쾌한 소식을 듣고 싶지 않을 것입니다.

새 OS를 실행하는 오래된 하드웨어는 새로운 기능이 일반적인 장치 작동을 방해하기 때문에 예기치 않은 동작을 유발할 수 있습니다. 따라서 다시 한 번 테스트하고, 테스트하고, 테스트하세요. 예를 들어 가상화 계층이 직접 하드웨어 액세스를 방해하거나 디바이스 간의 통신 속도를 저하시킬 수 있습니다.

 

 

 

숙련된 팀 구성

숙련된 팀 구성

 

마이그레이션 과정에는 많은 부분이 움직이며 문제가 쉽게 발생할 수 있습니다. 백업 복원부터 통합 및 모니터링, DB 전문가, 보안 전문가, 마이그레이션하는 OS와 실행 중인 소프트웨어의 전문가 등 적절한 전문가를 모두 확보해야 합니다.

일부 팀원이 외부에 있는 경우에도 필요한 경우 통화를 통해 온라인 상태로 전환할 수 있다면 괜찮습니다. SLA도 확인하고 공급업체의 지원 시간이 유지 보수 기간과 겹치는지 확인하세요.

 

 

2: 마이그레이션 단계

2: 마이그레이션 단계

 

마이그레이션 프로세스에 대해 설명하기 전에 문서화에 대한 간단한 참고 사항을 알려드리겠습니다. 다음 단계를 진행하면서 수행한 단계와 결과를 신중하게 문서화해야 합니다. 다음과 같은 요소를 고려하세요:

  • 예상치 못한 행동이나 성능을 발견한 모든 것
  • 완화해야 했던 비호환성 문제
  • 마이그레이션을 수용하기 위한 특별 구성 또는 사용자 지정 구성

두 가지 이유로 이 작업을 수행하는 것이 좋습니다. 첫째, 나중에 문제가 발생할 경우 근본 원인을 추적할 수 있는 가능성이 높아집니다. 또한 문서가 향후 유사한 마이그레이션을 위한 템플릿으로 사용될 수 있으므로 프로세스를 반복할 때 마찰을 줄일 수 있습니다.

 

1단계: 유지보수 기간 및 백업 시작

1단계: 유지보수 기간 및 백업 시작

 

팀이 준비되면 유지 보수 기간을 시작하고 시스템을 활성 사용 상태에서 제거할 수 있습니다. 원활하게 오프라인 상태로 전환하기 위해 수행해야 할 몇 가지 주요 단계가 있습니다:

  • 사용자 세션을 중지하되, 점진적인 방식으로 중지하는 것을 목표로 합니다.
  • 가능한 경우, 경계 방화벽에서 트래픽을 차단하여 외부 세계와 컴퓨터를 분리하세요.
  • 웹 서버, DB 서버, 파일 서버 등 합리적인 순서로 서비스 실행을 중지합니다.

시스템을 오프라인으로 전환한 직후에는 해당 상태의 시스템을 캡처하고 백업 후 보호되지 않은 변경이 이루어지지 않도록 하는 새로운 백업을 만들어야 합니다.

참고: 이 시점에서 백업 복원을 테스트하는 것이 중요합니다. 종종 잊어버리는 부분이지만 백업 복원은 가장 일반적인 장애 지점 중 하나입니다. 마이그레이션을 진행하기 전에 백업을 테스트하세요.

 

2단계: 새 OS 설치 및 구성하기

2단계: 새 OS 설치 및 구성하기

 

이제 새 OS를 설치할 차례입니다. 공식 업그레이드 경로를 사용할 수 있고 적절한 경우 이를 따르는 것이 좋지만, 경우에 따라서는 컴퓨터의 콘텐츠를 먼저 지운 후 새로 설치해야 할 수도 있습니다. 설치 또는 업그레이드 단계는 OS에 따라 다르므로 새 OS를 설치할 때 시간을 내어 공식 문서를 면밀히 살펴보는 것이 좋습니다.

필요한 경우 타사 드라이버를 추가하여 OS 설치를 따르세요. OS를 설치한 직후 하드웨어 테스트는 매우 중요하며, 대부분의 디바이스에는 몇 가지 유형의 테스트 기능이 있습니다.

그런 다음 요구 사항에 맞게 OS를 구성합니다. 다음 사항을 고려하세요:

  • 필요에 따라 시스템별 최적화를 수행합니다.
  • 필요한 경우 ID 공급자, 인증 메커니즘 및 디렉토리 서비스와 통합합니다.
  • 보안 서비스를 포함한 모니터링 도구 설치 - 보안 평가를 하기에 좋은 시기이기도 합니다.
  • 로컬 네트워킹 규칙과 방화벽을 구성하세요.

 

 

3단계: 특정 소프트웨어 설치 및 구성, 백업 복원

3단계: 특정 소프트웨어 설치 및 구성, 백업 복원

 

마지막 단계는 워크로드를 처리하는 소프트웨어를 다시 설치하고 구성하는 것입니다. 특정 통합, 최적화 및 사용자 지정 단계가 필요할 수 있습니다.

소프트웨어가 예상대로 실행되는지 확인하기 위해 이해관계자와 숙련된 직원을 참여시켜 검증해야 합니다. 이해관계자는 매일 소프트웨어를 사용하므로 시스템 관리자보다 장애를 더 쉽게 발견할 수 있습니다. 다음으로, 이 시점에 백업을 수행하여 필요한 경우 백업으로 돌아갈 수 있도록 하세요.

이제 유지 보수 기간을 종료할 수 있습니다. 자동으로 시작되지 않은 서비스를 다시 시작하고, 필요한 경우 경계 방화벽에서 통신을 다시 시작하세요.

 

3: 페일백 프로세스

3: 페일백 프로세스

 

업그레이드가 순조롭게 진행되어 모든 것이 정상적으로 작동하고 있기를 바랍니다. 하지만 문제가 발생한 경우 장애 복구 프로세스가 마련되어 있는지 확인해야 합니다.

앞의 두 단계에서 백업을 생성하고 테스트도 했을 것입니다. 유지 보수 기간 동안 마이그레이션이 실패하는 경우 프로세스를 시작할 때 만든 이 백업으로 되돌아가서 최대한 빨리 시스템을 작동 상태로 복원하는 데 시간을 낭비하지 않아야 합니다:

  • 사용자에게 미치는 영향 최소화
  • 다운타임을 과도하게 연장하여 규정 준수 조치를 위반하고 이해 관계자를 화나게 하지 않도록 합니다.
  • 테스트 시나리오를 반복하고, 블록을 식별하고, 복구 프로세스를 문서화하는 등 무엇이 잘못되었는지 평가할 수 있는 기회를 얻으세요.

마지막으로 장애 복구에 대한 참고 사항으로, 마이그레이션 전에 시스템 동기화를 해제했다는 사실은 시스템을 다른 시스템과 다시 통합하기 위해 특정 단계를 수행해야 한다는 것을 의미할 수 있다는 점에 유의하세요. 이는 백업과 복원 사이에 상당한 시간이 경과한 경우 특히 문제가 될 수 있습니다. 예를 들어 이 과정에서 도메인 컨트롤러의 동기화가 해제될 수 있습니다. 이에 대비하세요.

 

지금 업그레이드하거나 시간을 벌기

지금 업그레이드하거나 시간을 벌기

 

위의 마이그레이션 체크리스트를 읽은 후 마이그레이션을 계획하고 마이그레이션을 수행하는 데 시간이 걸린다는 사실을 알게 되었다면 마이그레이션 프로세스를 구성하는 동안 시스템을 안전하게 유지할 수 있는 몇 가지 대안을 고려할 수 있습니다.

한 가지 옵션은 네트워크 조닝을 통해 취약한 시스템을 보호하거나 정교한 방화벽에 의존하는 것입니다. 두 가지 방법 모두 완벽하지는 않습니다. 또 다른 옵션은 공급업체로부터 ELS(Lifecycle 연장 지원)를 받는 것이지만, 사용 중인 운영 체제에 따라 비용이 천차만별일 수 있습니다.

 

CloudLinux의 ELS 고려

CloudLinux의 Lifecycle 연장 지원 서비스 고려하기

 

대안으로, CloudLinux의 Lifecycle 연장 지원 서비스는 공급업체 지원에 비해 훨씬 더 저렴합니다. 최소한의 월 사용료로 CentOS 및 Ubuntu를 비롯한 여러 주요 Linux 배포판 중 하나에 대한 연장 지원을 구매할 수 있으며, CloudLinux의 Lifecycle 연장 지원 서비스는 Lifecycle이 다한 운영 체제를 보안 위협으로부터 보호하는 중요한 보안 업데이트를 제공합니다.

선택할 수 있는 유일한 옵션은 아무것도 하지 않는 것입니다. 지원되지 않는 운영 체제를 계속 사용하면 엔터프라이즈 워크로드가 감당할 수 없는 위험에 처하게 됩니다. 마이그레이션을 계획하거나 지금 Lifecycle 연장 지원을 구매하세요.

 

7일 지원되는 KernelCare 무료 체험판 받기 

 

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기