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로 마이그레이션하려면 다음을 수행합니다.
- RHEL 6 서버에서 RHEL 7 서버로 마이그레이션합니다. Red Hat Enterprise Linux 6에서 버전 7로 Identity Management 마이그레이션을 참조하십시오.
- 이 섹션에 설명된 대로 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으로 마이그레이션할 수도 있습니다.
주요 마이그레이션 절차에는 다음이 포함됩니다.
- RHEL 8 IdM 서버를 구성하고 현재 RHEL 7 IdM 환경에 복제본으로 추가합니다. 자세한 내용은 RHEL 8 Replica 설치를 참조하십시오.
- RHEL 8 서버를 CA(인증 기관) 갱신 서버로 설정합니다. 자세한 내용은 RHEL 8 IdM 서버에 CA 갱신 서버 역할 할당을 참조하십시오.
- RHEL 7 서버에서 CRL(인증서 취소 목록) 생성을 중지하고 CRL 요청을 RHEL 8로 리디렉션합니다. 자세한 내용은 RHEL 7 IdM CA 서버에서 CRL 생성 중지 를 참조하십시오.
- RHEL 8 서버에서 CRL 생성을 시작합니다. 자세한 내용은 새로운 RHEL 8 IdM CA 서버에서 CRL 생성 시작을 참조하십시오.
- 원본 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 갱신 서버로 설정, 이전 서버 해제)는 모든 배포에 적용되지만 대규모 환경은 보다 엄격한 인벤토리 및 검증 프로세스의 이점을 누릴 수 있습니다.
마이그레이션 워크플로 비교
다음 표에는 표준 단일 서버 또는 소규모 클러스터 마이그레이션에 비해 대규모 또는 복잡한 토폴로지에 권장되는 추가 단계가 표시되어 있습니다.
| 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. 클라이언트 설정 업데이트 | 자동(대부분). |
수동 업데이트가 필요할 수 있습니다. |
| 8. 이전 서버 해제 | 필수 항목입니다. | 필수 항목입니다. 고유한 역할이 손실되지 않고 복제가 수렴할 수 있는지 확인합니다. |
대규모 배포를 위한 전략적 고려 사항
- 중복 유지 관리: 복제본을 해제하기 전에 하나 이상의 다른 서버가 중요한 서비스(CA, DNS, KRA, AD Trust)를 제공하도록 합니다.
- 복제 Lag: 지리적으로 분산된 배포에서 복제를 위해 토폴로지 변경 간 추가 시간을 허용합니다. 빠른 제거/추가 주기는 지연 시간이 긴 링크에서 해결하기 어려운 충돌을 생성할 수 있습니다.
- 일괄 처리: 매우 큰 토폴로지를 위해 사이트별로 마이그레이션하여 각 파동 후 상태를 검증합니다. 단일 사이트의 모든 서버를 동시에 해제하지 마십시오.