2장. RHEL 7 서버에서 RHEL 8 서버로 IdM 환경 마이그레이션


RHEL 7 IdM 환경을 RHEL 8로 업그레이드하려면 먼저 RHEL 7 IdM 환경에 새 RHEL 8 IdM 복제본을 추가한 다음 RHEL 7 서버를 폐기해야 합니다.

주의
  • RHEL 7 IdM 서버 및 IdM 서버 노드를 RHEL 8로 인플레이스 업그레이드를 수행하는 것은 지원되지 않습니다.
  • RHEL 6 또는 이전 버전에서 RHEL 8로 직접 마이그레이션하는 것은 지원되지 않습니다. IdM 데이터를 올바르게 업데이트하려면 증분 마이그레이션을 수행해야 합니다.

    예를 들어 RHEL 6 IdM 환경을 RHEL 8로 마이그레이션하려면 다음을 수행합니다.

    1. RHEL 6 서버에서 RHEL 7 서버로 마이그레이션합니다. Red Hat Enterprise Linux 6에서 버전 7로 Identity Management 마이그레이션을 참조하십시오.
    2. 이 섹션에 설명된 대로 RHEL 7 서버에서 RHEL 8 서버로 마이그레이션합니다.
중요

RHEL 8은 SPAKE 및 IdP 사전 인증을 지원하지만 RHEL 7은 지원하지 않습니다. RHEL 7 IdM 배포에서 SPAKE 또는 IdP가 활성화된 RHEL 8 서버가 있으면 로그인할 수 없는 사용자와 같은 문제가 발생할 수 있습니다. 따라서 IdM 배포의 모든 서버를 최대한 빨리 마이그레이션합니다.

자세한 내용은 kerberos의 Red Hat Knowledgebase 솔루션 사전 인증 오류AD 신뢰 사용자에게 2FA/OTP 인증 사용을 참조하십시오.

다음 절차에서는 RHEL(Red Hat Enterprise Linux) 7 서버에서 RHEL 8 서버로 모든 IdM(Identity Management) 데이터 및 구성을 마이그레이션하는 방법을 설명합니다. 이 절차를 사용하여 RHEL이 아닌 Linux 배포판의 FreeIPA 서버에서 RHEL 8 서버의 IdM으로 마이그레이션할 수도 있습니다.

주요 마이그레이션 절차에는 다음이 포함됩니다.

  1. RHEL 8 IdM 서버를 구성하고 현재 RHEL 7 IdM 환경에 복제본으로 추가합니다. 자세한 내용은 RHEL 8 Replica 설치를 참조하십시오.
  2. RHEL 8 서버를 CA(인증 기관) 갱신 서버로 설정합니다. 자세한 내용은 RHEL 8 IdM 서버에 CA 갱신 서버 역할 할당을 참조하십시오.
  3. RHEL 7 서버에서 CRL(인증서 취소 목록) 생성을 중지하고 CRL 요청을 RHEL 8로 리디렉션합니다. 자세한 내용은 RHEL 7 IdM CA 서버에서 CRL 생성 중지 를 참조하십시오.
  4. RHEL 8 서버에서 CRL 생성을 시작합니다. 자세한 내용은 새로운 RHEL 8 IdM CA 서버에서 CRL 생성 시작을 참조하십시오.
  5. 원본 RHEL 7 CA 업데이트 서버 중지 및 해제. 자세한 내용은 RHEL 7 서버 중지 및 해제를 참조하십시오.

대규모 또는 복잡한 배포를 위한 추가 절차

토폴로지 상태를 유지하고 서비스 중단을 방지하기 위해 지리적으로 배포되거나 미션 크리티컬한 IdM 배포에는 다음 선택적 절차를 사용하는 것이 좋습니다.

마이그레이션을 시작하기 전에 전략 지침을 검토하고 배포에 적용되는 선택적 절차를 고려하십시오.

다음 절차에서는 다음을 수행합니다.

  • rhel8.example.com 은 새 CA 갱신 서버가 될 RHEL 8 시스템입니다.
  • rhel7.example.com 은 원래 RHEL 7 CA 갱신 서버입니다.

    IdM 배포에서 CA(인증 기관)를 사용하지 않는 경우 RHEL 7에서 실행 중인 모든 IdM 서버는 rhel7.example.com 일 수 있습니다.

2.1. 대규모 및 표준 IdM 배포를 마이그레이션하기 위한 전략

대규모 또는 지리적으로 분산된 IdM(Identity Management) 토폴로지를 마이그레이션하려면 서비스 연속성을 보장하기 위해 추가 계획이 필요합니다. 핵심 마이그레이션 단계(새 복제본 설치, CA 갱신 서버로 설정, 이전 서버 해제)는 모든 배포에 적용되지만 대규모 환경은 보다 엄격한 인벤토리 및 검증 프로세스의 이점을 누릴 수 있습니다.

마이그레이션 워크플로 비교

다음 표에는 표준 단일 서버 또는 소규모 클러스터 마이그레이션에 비해 대규모 또는 복잡한 토폴로지에 권장되는 추가 단계가 표시되어 있습니다.

Expand
Step표준 마이그레이션대규모/Complex 마이그레이션

1. 인벤토리 토폴로지

선택 사항:

강하게 권장하고 있습니다. 복제본 교체 중에 중요한 서비스(CA, DNS, KRA, AD Trust)가 손실되지 않도록 모든 서버 역할 및 복제 계약을 문서화합니다.

2. DNA ID 범위 기록

선택 사항:

강하게 권장하고 있습니다. 다시 할당하지 않고 대규모 범위를 보유한 서버가 해제되는 경우 소진을 방지하기 위해 레코드가 할당된 ID 범위입니다.

3. 서버 호스트 이름 재사용

거의 필요하지 않습니다.

Condition입니다. 호스트 이름을 다시 사용하는 경우 복제가 완전히 통합될 때까지 기다린 후 다시 설치합니다. 빠른 제거 및 추가는 대기 시간이 긴 토폴로지에서 충돌을 일으킬 수 있습니다.

4. 새 복제본 설치

필수 항목입니다.

필수 항목입니다. 새 복제본이 교체된 것과 동일한 역할로 설치되었는지 확인합니다. 확인 중에 Healthcheck을 실행하여 문제를 조기에 파악합니다.

5. CA 갱신 역할 할당

필수(통합 CA를 사용하는 경우).

필수(통합 CA를 사용하는 경우). 계속하기 전에 역할 할당 복제를 확인합니다.

6. CRL 생성 관리

필수(통합 CA를 사용하는 경우).

필수(통합 CA를 사용하는 경우). 이전 서버에서 CRL을 중지하고 요청을 리디렉션하고 새 서버에서 시작합니다.

7. 클라이언트 설정 업데이트

자동(대부분).

수동 업데이트가 필요할 수 있습니다. ipa.conf 또는 sssd.conf 의 특정 서버에 고정된 클라이언트는 새 복제본을 가리키도록 업데이트해야 합니다.

8. 이전 서버 해제

필수 항목입니다.

필수 항목입니다. 고유한 역할이 손실되지 않고 복제가 수렴할 수 있는지 확인합니다.

대규모 배포를 위한 전략적 고려 사항

  • 중복 유지 관리: 복제본을 해제하기 전에 하나 이상의 다른 서버가 중요한 서비스(CA, DNS, KRA, AD Trust)를 제공하도록 합니다.
  • 복제 Lag: 지리적으로 분산된 배포에서 복제를 위해 토폴로지 변경 간 추가 시간을 허용합니다. 빠른 제거/추가 주기는 지연 시간이 긴 링크에서 해결하기 어려운 충돌을 생성할 수 있습니다.
  • 일괄 처리: 매우 큰 토폴로지를 위해 사이트별로 마이그레이션하여 각 파동 후 상태를 검증합니다. 단일 사이트의 모든 서버를 동시에 해제하지 마십시오.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat