SUSE Multi-Linux Manager 서버를 컨테이너화된 환경으로 마이그레이션

1. 요구 사항 및 고려 사항

1.1. 일반 요구사항

  • SUSE Multi-Linux Manager 4.3 서버를 컨테이너 환경으로 마이그레이션하려면 SL Micro 6.1 또는 SUSE Linux Enterprise Server 15 SP7 및 `mgradm`가 설치된 새로운 머신이 필요합니다.

  • SUSE Multi-Linux Manager 4.3에서 5.1로의 인플레이스 마이그레이션은 지원되지 않으며, 선택한 호스트 운영 체제가 SL Micro 6.1 또는 SUSE Linux Enterprise Server 15 SP7인 경우에도 마찬가지입니다.

  • SUSE Multi-Linux Manager 4.3에서 5.1로 마이그레이션하기 전에 기존 전통 클라이언트와 전통 프록시를 포함한 모든 기존 클라이언트를 Salt로 마이그레이션해야 합니다. 전통적인 SUSE Multi-Linux Manager 4.3 클라이언트를 Salt 클라이언트로 마이그레이션하는 방법에 대한 자세한 내용은 Migrate Traditional Clients to Salt Clients를 참조하십시오.

  • 전통적인 연락 프로토콜은 SUSE Multi-Linux Manager 5.0 이상에서 더 이상 지원되지 않습니다.

이 가이드는 SUSE Multi-Linux Manager 4.3에서 5.1로의 마이그레이션만 다룹니다.

기존 SUSE Multi-Linux Manager 5.1 인스턴스를 동일한 버전으로 마이그레이션하면서 호스트 운영 체제를 SL Micro 6.1에서 SUSE Linux Enterprise Server 15 SP7으로 변경하거나 그 반대의 경우는 mgradm migrate 명령으로 처리되지 않습니다.

1.2. 호스트 이름

  • 현재 마이그레이션 절차에는 호스트 이름을 변경하는 기능이 포함되어 있지 않습니다. 그 결과, 새 서버의 완전한 도메인 이름(FQDN)은 이전 서버와 동일하게 유지됩니다.

  • 클라이언트가 서버에 연결할 수 있도록 IP 주소는 변경되지 않은 상태로 유지해야 합니다.

마이그레이션 후에는 DHCP 및 DNS 레코드를 수동으로 업데이트하여 새 서버를 가리키도록 해야 합니다.

1.3. GPG 키

  • 자체 신뢰 GPG 키는 마이그레이션되지 않습니다.

  • RPM 데이터베이스에서만 신뢰되는 GPG 키는 마이그레이션되지 않습니다. 따라서 `spacewalk-repo-sync`을(를) 사용한 채널 동기화가 실패할 수 있습니다.

  • 관리자는 실제 서버 마이그레이션을 수행한 후 이러한 키를 4.3 설치에서 컨테이너 호스트로 수동으로 마이그레이션해야 합니다.

    절차 4.3 GPG 키를 새 서버로 수동으로 마이그레이션합니다.

    1. 4.3 서버의 키를 새 서버의 컨테이너 호스트로 복사합니다.

    2. 그 후, 명령 `mgradm gpg add <PATH_TO_KEY_FILE>`를 사용하여 마이그레이션된 서버에 각 키를 추가합니다.

1.4. SSL 인증서

마이그레이션 과정 중에 서버 SSL 인증서와 CA 체인은 소스 서버에서 복사되므로, 데이터베이스 인증서만 필요합니다.

SUSE Multi-Linux Manager 5.1부터 PostgreSQL 데이터베이스는 마이그레이션 중에 자체 SSL 인증서가 필요한 별도의 컨테이너에서 실행됩니다. 이것이 서버 인증서와 CA 체인이 소스에서 복사되더라도 데이터베이스 인증서가 필요한 이유입니다.

이미 SUSE Multi-Linux Manager 4.3 설치에서 사용 중인 타사 인증서는 마이그레이션 중에 자동으로 복사됩니다. 대부분의 시나리오에 대해 추가 구성은 필요하지 않습니다.

마이그레이션을 수행할 때, SUSE Multi-Linux Manager은 기본적으로 자체 서명된 인증서를 사용합니다. 외부 PKI(인증 기관)의 인증서를 사용하려면, mgradm migrate 실행 시 --ssl* 플래그를 사용하여 모든 인증서 파일을 제공할 수 있습니다.

Table 1. 빠른 참조: 마이그레이션에 필요한 플래그는 무엇인가요?
마이그레이션 상황 필요한 플래그

자체 서명된 CA, 모든 것이 변경되지 않음

없음

새 서버 인증서(동일한 CA)

--ssl-server-cert, --ssl-server-key

새 데이터베이스 인증서(동일한 CA)

--ssl-db-cert, --ssl-db-key

새 서버 및 데이터베이스 인증서(동일한 CA)

--ssl-server-cert, --ssl-server-key, --ssl-db-cert, --ssl-db-key

새 서버 인증서 + 새 CA

--ssl-server-cert, --ssl-server-key, --ssl-ca-root, --ssl-ca-intermediate

새 데이터베이스 인증서 + 새 CA

--ssl-db-cert, --ssl-db-key, --ssl-db-ca-root, --ssl-db-ca-intermediate

CA만 변경(동일한 인증서 파일, 다른 CA 체인)

--ssl-ca-root, --ssl-ca-intermediate, --ssl-db-ca-root, --ssl-db-ca-intermediate

전체 교체 — 두 구성 요소 모두에 대한 새 인증서 및 CA

아래의 "외부 PKI의 모든 인증서"를 참조하십시오.

지정되지 않은 --ssl* 플래그는 소스 서버의 해당 값을 사용합니다. 현재 설정과 다른 파일에 대해서만 플래그를 제공하십시오.

1.4.1. 플래그 참조

다음 --ssl* 플래그는 `mgradm migrate`에서 지원됩니다:

플래그 설명

--ssl-ca-root

서버 인증서를 서명한 루트 CA 인증서의 경로(기본값: 소스 서버 CA)

--ssl-ca-intermediate

체인 내 중간 CA 인증서의 경로(여러 번 지정할 수 있음; 기본값: 소스 서버)

--ssl-server-cert

서버 인증서의 경로(기본값: 소스 서버 인증서)

--ssl-server-key

서버 개인 키의 경로(기본값: 소스 서버 키)

--ssl-db-ca-root

데이터베이스 인증서를 서명한 루트 CA 인증서의 경로

--ssl-db-ca-intermediate

데이터베이스 인증서 체인의 중간 CA 인증서 경로(여러 번 지정할 수 있음)

--ssl-db-cert

데이터베이스 인증서의 경로

--ssl-db-key

데이터베이스 개인 키의 경로

데이터베이스 인증서 체인은 서버 인증서 체인과 완전히 별개입니다. 같은 CA를 사용할 때에도 --ssl-db-* 플래그를 제공해야 하며, 데이터베이스 컨테이너는 마이그레이션 중에 생성된 자체 인증서를 필요로 합니다.

1.4.2. 인증서 요구 사항

다음 요구 사항은 `mgradm migrate`와 함께 사용되는 모든 인증서 파일에 적용됩니다:

  • 모든 인증서 파일은 PEM 형식이어야 합니다. 인증서가 DER 형식인 경우, 먼저 변환해야 합니다.

  • 인증서의 X509v3 Subject Alternative Name 섹션에 있는 호스트 이름은 인증서가 배포된 머신의 완전한 호스트 이름과 일치해야 합니다.

  • 데이터베이스 인증서에는 reportdb 및 db`가 `Subject Alternative Name(SAN)으로 필요합니다.

  • 지원되는 키 유형은 RSA 및 EC(타원 곡선)입니다.

  • CA 체인을 사용할 때는 인증서를 서버 또는 데이터베이스 인증서를 먼저 두고, 그 다음에 모든 중간 CA 인증서를 순서대로 이어 붙입니다. 루트 CA 인증서는 별도의 파일로 제공해야 합니다. 파일을 결합하려면 다음 명령을 사용할 수 있습니다:

    cat server.pem intermediate-ca1.pem intermediate-ca2.pem > combined-server.pem

인증서 준비에 대한 자세한 내용은 SSL 인증서 가져오기를 참조하십시오.

1.4.3. 시나리오: 외부 PKI의 모든 인증서

이 시나리오는 웹 및 데이터베이스 구성 요소가 제3자 CA의 인증서를 사용하는 서버로의 마이그레이션을 다룹니다. 조직은 다음 인증서 파일을 수집해야 합니다.

  • 웹 구성 요소용 루트 CA 인증서

  • 웹 구성 요소용 중간 CA 인증서(해당되는 경우)

  • 웹 구성 요소용 서버 인증서

  • 웹 구성 요소용 개인 키

  • 데이터베이스 구성 요소용 루트 CA 인증서

  • 데이터베이스 구성 요소용 중간 CA 인증서(해당되는 경우)

  • 데이터베이스 구성 요소용 서버 인증서(reportdb 및 `db`를 SAN으로 포함)

  • 데이터베이스 구성 요소용 개인 키

대부분의 배포에서 단일 CA가 서버 및 데이터베이스 구성 요소 모두에 서비스를 제공합니다. 이 경우 동일한 인증서 파일이 --ssl- 및 --ssl-db- 플래그 모두에 사용됩니다. 아래 예제는 명확성을 위해 별도의 파일 이름을 사용합니다.

Listing 1. 모든 --ssl* 플래그가 포함된 예제 마이그레이션 명령입니다.
mgradm migrate podman <oldserver.fqdn> \
  --ssl-ca-root rootCAweb.pem \
  --ssl-ca-intermediate intermediateCAweb.pem \
  --ssl-server-cert webcert.pem \
  --ssl-server-key webkey.key \
  --ssl-db-ca-root rootCAdb.pem \
  --ssl-db-ca-intermediate intermediateCAdb.pem \
  --ssl-db-cert dbcert.pem \
  --ssl-db-key dbkey.key
외부 CA 인증서의 클라이언트 배포

외부 PKI 인증서로 성공적으로 마이그레이션한 후, 모든 클라이언트에 CA 인증서를 배포하여 새로운 서버 인증서를 검증할 수 있도록 합니다.

mgrctl exec -- 'salt -b 50 * state.apply certs'

1.4.4. 시나리오: 혼합된 외부 및 자체 서명된 인증서

외부 및 자체 서명된 인증서가 혼합된 상태로 마이그레이션할 때, 서버 또는 데이터베이스 인증서와 해당 개인 키도 동일한 체인에서 교체되는 경우에만 인증서 체인의 CA를 교체하십시오. 예를 들어, 서버 인증서와 키를 외부 PKI 버전으로 교체할 때, 해당 CA 인증서도 제공해야 합니다. 그러나 데이터베이스 인증서만 교체할 경우, 원래 CA를 재사용하는 경우에는 자체 서명된 CA 비밀번호가 여전히 필요합니다.

전체 절차에 대한 내용은 SCC 문서: SUSE Multi-Linux Manager 서버 마이그레이션 실패 원인 (또는 분실된) CA 비밀번호를 참조하십시오.

2. 마이그레이션

2.1. SUSE Multi-Linux Manager 5.1 서버 호스트 준비

준비된 SL Micro 6.1 또는 SUSE Linux Enterprise Server 15 SP7 시스템에 SUSE Multi-Linux Manager을 미리 설치하지 마십시오.

마이그레이션 프로세스는 서버 설치를 자동으로 수행하도록 설계되었습니다. `mgradm install`을(를) 실행한 다음 `mgradm migrate`을(를) 실행하는 것은 지원되지 않으며 지원되지 않는 시스템 상태를 초래합니다.

다음 단계에서는 호스트 시스템만 준비하며 실제 SUSE Multi-Linux Manager 5.1 서버는 설치하지 않습니다.

SL Micro 6.1를 기반으로 한 VM 이미지를 마이그레이션 대상으로 사용할 수 있습니다. 이러한 시나리오에서는 다음에 설명된 대로 호스트 시스템을 준비할 수 있습니다.

그러나 마지막 단계에서는 mgradm migrate <FQDN> 대신에 mgradm install <FQDN> 명령을 실행합니다.

2.1.1. SL Micro 6.1 호스트를 준비합니다.

2.1.1.1. 작업: 설치 미디어 다운로드
절차 설치 미디어 다운로드 중

  1. https://www.suse.com/download/sle-micro/,에서 SL Micro 6.1 설치 미디어를 찾아 적절한 미디어 파일을 다운로드합니다.

  2. 설치를 위해 다운로드한 .iso 이미지가 들어 있는 DVD 또는 USB 메모리 키를 준비합니다.

2.1.1.2. SL Micro 6.1 설치
절차 SL Micro 6.1 설치 중

  1. SLE Micro 6.1의 설치 이미지가 들어 있는 DVD 또는 USB 메모리 키(USB 디스크 또는 키)를 삽입합니다.

  2. 시스템을 부팅하거나 재부팅합니다.

  3. 화살표 키를 사용하여 `Installation`을(를) 선택합니다.

  4. 키보드 및 언어를 조정합니다.

  5. 라이선스 계약에 동의하려면 `checkbox`을(를) 클릭합니다.

  6. 계속하려면 `Next`을(를) 클릭합니다.

  7. 등록 방법을 선택합니다. 이 예제에서는 SUSE Customer Center에 서버를 등록합니다.

    SUSE Multi-Linux Manager 5.1 컨테이너는 확장으로 설치됩니다. 아래 목록에서 필요한 특정 확장에 따라 각 SUSE Customer Center 활성화 코드가 추가로 필요합니다.

    • SUSE Multi-Linux Manager 5.1 서버

    • SUSE Multi-Linux Manager 5.1 프록시

    • SUSE Multi-Linux Manager 5.1 리테일 분기 서버

    SL Micro 6.1 권한은 SUSE Multi-Linux Manager 권한에 포함되어 있으므로 별도의 활성화 코드가 필요하지 않습니다.

  8. SUSE Customer Center 이메일 주소를 입력합니다.

  9. SL Micro 6.1 활성화 코드를 입력합니다.

  10. 계속하려면 `Next`을(를) 클릭합니다.

  11. 프록시를 설치하려면 SUSE Multi-Linux Manager 5.1 프록시 확장 프로그램을 선택하고, 서버를 설치하려면 SUSE Multi-Linux Manager 5.1 서버 확장 프로그램 `Checkbox`을(를) 선택합니다.

  12. 계속하려면 `Next`을(를) 클릭합니다.

  13. SUSE Multi-Linux Manager 5.1 확장 프로그램 활성화 코드를 입력합니다.

  14. 계속하려면 다음을 클릭합니다.

  15. NTP Configuration 페이지에서 다음을(를) 클릭합니다.

  16. Authentication for the System 페이지에서 루트의 암호를 입력합니다. 다음을 클릭합니다.

  17. Installation Settings 페이지에서 설치를 클릭합니다.

이로써 SL Micro 6.1 및 SUSE Multi-Linux Manager 5.1의 확장 프로그램 설치가 완료되었습니다. 가상 또는 물리적 머신 준비에 대한 자세한 내용은 SL Micro 배포 가이드를 참조하십시오.

2.1.1.3. 선택 사항: 명령줄에서 등록

설치 중에 SUSE Multi-Linux Manager 5.1를 확장으로 추가한 경우 이 절차를 건너뛸 수 있습니다. 그러나 선택적으로 SL Micro 6.1 설치 중에 등록 건너뛰기 버튼을 선택하여 등록을 건너뛸 수 있습니다. 이 섹션에서는 SL Micro 6.1 설치 후 제품 등록 단계에 대해 설명합니다.

다음 단계는 SUSE Multi-Linux Manager 5.1 확장을 x86-64 아키텍처로 등록하며, 따라서 x86-64 아키텍처에 대한 활성화 코드가 필요합니다. ARM 또는 s390x 아키텍처를 등록하려면 올바른 활성화 코드를 사용하십시오.
절차 명령줄에서 등록

  1. 다음 명령을 실행하여 타이머를 비활성화할 수 있습니다.

    transactional-update --quiet register --list-extensions

  2. 다음 명령을 실행하여 타이머를 비활성화할 수 있습니다.

    1. 서버를 설치하는 경우 다음 명령어와 함께 SUSE Multi-Linux Manager 서버 확장 5.1 x86_64 활성화 코드를 사용하십시오:

      transactional-update register -p Multi-Linux-Manager-Server/5.1/x86_64 -r <reg_code>

    2. 프록시를 설치하는 경우 다음 명령어와 함께 SUSE Multi-Linux Manager 프록시 확장 5.1 x86_64 활성화 코드를 사용하십시오:

    transactional-update register -p Multi-Linux-Manager-Proxy/5.1/x86_64 -r <reg_code>

  3. 재부팅합니다.

2.1.1.4. 시스템 업데이트
절차 시스템 업데이트 중

  1. *루트*로 로그인합니다.

  2. 트랜잭션 업데이트 실행:

    transactional-update

  3. 재부팅합니다.

SL Micro은 기본적으로 자동으로 업데이트되도록 설계되었으며 업데이트 적용 후 재부팅됩니다. 그러나 이 동작은 SUSE Multi-Linux Manager 환경에서는 바람직하지 않습니다. 서버에서 자동 업데이트를 방지하기 위해 SUSE Multi-Linux Manager 부팅 과정 중에 트랜잭션 업데이트 타이머를 비활성화합니다.

SL Micro 기본 동작을 사용하려면 다음 명령을 실행하여 타이머를 활성화합니다.

systemctl enable --now transactional-update.timer

2.1.2. SUSE Linux Enterprise Server 15 SP7 호스트를 준비합니다.

대안으로, SUSE Multi-Linux Manager을 SUSE Linux Enterprise Server 15 SP7에 배포할 수 있습니다.

다음 절차에서는 설치 과정의 주요 단계를 설명합니다.

2.1.2.1. SUSE Multi-Linux Manager 확장 프로그램을 SUSE Linux Enterprise Server에 설치합니다.
절차 SUSE Multi-Linux Manager 확장 프로그램을 SUSE Linux Enterprise Server에 설치하는 중입니다.

  1. SUSE Linux Enterprise Server 15 SP7 `.iso`를 https://www.suse.com/download/sles/.에서 찾아 다운로드합니다.

  2. 호스트 운영 체제(SUSE Linux Enterprise Server 15 SP7) 및 확장 프로그램 모두에 대한 활성화 코드가 반드시 있어야 합니다.

  3. SUSE Linux Enterprise Server 15 SP7의 설치를 시작합니다.

    1. `Language, keyboard and product selection`에서 설치할 제품을 선택합니다.

    2. `License agreement`에서 계약서를 읽고 `I Agree to the License Terms`을(를) 확인합니다.

  4. 등록 방법을 선택합니다. 이 예제에서는 SUSE 고객 센터에 서버를 등록합니다.

  5. SUSE Customer Center 이메일 주소를 입력합니다.

  6. SUSE Linux Enterprise Server 15 SP7에 대한 활성화 코드를 입력합니다.

  7. 계속하려면 `Next`을(를) 클릭합니다.

    SUSE Linux Enterprise Server 15 SP7에 대해 유효한 SUSE Linux Enterprise Server 구독 및 해당 활성화 코드가 필요합니다. 이 화면에서 제공해야 합니다. 아래에 SUSE Multi-Linux Manager 확장 프로그램 활성화 코드를 입력해야 합니다.

  8. 화면 `Extensions and Modules Selection`에서 다음 사항을 확인합니다:

    • 서버를 설치하려면 SUSE Multi-Linux Manager 서버 확장 프로그램을 선택하고, 프록시를 설치하려면 SUSE Multi-Linux Manager 프록시 확장 프로그램을 선택합니다.

    • Basesystem 모듈

    • 컨테이너 모듈

  9. 계속하려면 `Next`을(를) 클릭합니다.

  10. SUSE Multi-Linux Manager 5.1 확장 프로그램 활성화 코드를 입력합니다.

  11. 계속하려면 다음을 클릭합니다.

  12. 설치를 완료합니다.

  13. 설치가 완료되면 새로 설치된 서버에 루트 권한으로 로그인합니다.

  14. 시스템 업데이트(선택 사항, 설치 중에 시스템이 업데이트를 다운로드하도록 설정되지 않은 경우):

    zypper up

  15. 재부팅합니다.

2.1.2.2. 선택 사항: 명령줄에서 등록

SUSE Linux Enterprise Server 설치 중에 SUSE Multi-Linux Manager 5.1를 확장 프로그램으로 추가한 경우 이 절차를 건너뛸 수 있습니다.

그러나 선택적으로 SUSE Linux Enterprise Server 설치 중에 등록 건너뛰기 버튼을 선택하여 등록을 건너뛸 수 있습니다. 이 섹션에서는 SUSE Linux Enterprise Server 설치 후 제품 등록 단계에 대해 설명합니다.

다음 단계는 x86-64 아키텍처에 대한 활성화 코드가 필요하므로 SUSE Multi-Linux Manager 5.1 확장을 x86-64 아키텍처로 등록합니다.

ARM 또는 s390x 아키텍처를 등록하려면 올바른 활성화 코드를 사용하십시오.
절차 명령줄에서 등록

  1. 다음 명령을 실행하여 타이머를 비활성화할 수 있습니다.

    SUSEConnect --list-extensions

  2. 다음 명령을 실행하여 타이머를 비활성화할 수 있습니다.

    • 서버를 설치하는 경우, SUSE Multi-Linux Manager 서버 확장 프로그램 5.1 x86_64 활성화 코드를 사용하십시오.

      예를 들어 SUSE Linux Enterprise 15 SP7의 경우 다음 명령을 사용하십시오:

      SUSEConnect -r <regcode>
SUSEConnect -p sle-module-containers/15.7/x86_64
SUSEConnect -p Multi-Linux-Manager-Server-SLE/5.1/x86_64 -r <regcode>

    • 프록시를 설치하는 경우, SUSE Multi-Linux Manager 프록시 확장 프로그램 5.1 x86_64 활성화 코드를 다음 명령과 함께 사용하십시오.

    SUSEConnect -p Multi-Linux-Manager-Proxy-SLE/5.1/x86_64 -r <regcode>
2.1.2.3. `podman`을(를) 설치하고 활성화합니다.
절차 podman 설치 중

  1. 컨테이너 호스트에서 ``root``로 로그인합니다.

    • 서버를 재부팅합니다.

      zypper in podman
zypper in -t product Multi-Linux-Manager-Server-SLE

    • 프록시에서:

      zypper in podman
zypper in -t product Multi-Linux-Manager-Proxy-SLE

      패키지 podman`이(가) 설치되어 있는지 확인하십시오. 또한, 서버 `mgradm 및 mgradm-bash-completion 또는 프록시에서 mgrpxy 및 `mgrpxy-bash-completion`도 설치해야 합니다.

  2. 시스템을 재부팅하거나 다음 명령을 실행하여 podman 서비스 시작:

    systemctl enable --now podman.service

2.2. SSH 연결 준비

이 단계는 새 SUSE Multi-Linux Manager 5.1 서버가 기존 4.3 서버에 SSH를 통해 비밀번호 없이 연결할 수 있도록 보장합니다. 여기에는 SSH 키를 생성하고 구성하고, SSH 에이전트를 설정하며, 공용 키를 이전 서버에 복사하는 과정이 포함됩니다. 마이그레이션 프로세스를 수동 개입 없이 실행하려면 이 설정이 필요합니다.

절차 SSH 연결 준비

  1. 새 root 서버에 대해 5.1의 SSH 키가 존재하는지 확인합니다. 키가 존재하지 않으면 다음 명령을 사용하여 생성합니다:

    ssh-keygen -t rsa

  2. 새 서버에서 비밀번호를 요청하지 않는 4.3 서버에 연결할 수 있도록 SSH 구성 및 에이전트가 준비되어 있어야 합니다.

    eval $(ssh-agent); ssh-add

    비밀번호 입력을 요구하지 않고 연결을 설정하기 위해 마이그레이션 스크립트는 새 서버에서 실행 중인 SSH 에이전트에 의존합니다. 에이전트가 아직 활성화되지 않았다면, eval $(ssh-agent)`를 실행하여 시작합니다. 그런 다음, 실행 중인 에이전트에 SSH 키를 추가할 때 `ssh-add 명령 뒤에 개인 키의 경로를 입력합니다. 이 과정에서 개인 키의 비밀번호를 입력하라는 메시지가 표시됩니다.

  3. 공용 SSH 키를 SUSE Multi-Linux Manager 4.3 서버(<oldserver.fqdn>)에 `ssh-copy-id`를 사용하여 복사합니다. `<oldserver.fqdn>`을(를) 4.3 서버의 FQDN으로 교체합니다:

    ssh-copy-id <old server.fqdn>

    SSH 키가 이전 서버의 ~/.ssh/authorized_keys 파일에 복사됩니다. 자세한 내용은 ssh-copy-id 매뉴얼 페이지를 참조하십시오.

  4. 새 서버에서 이전 SUSE Multi-Linux Manager 서버로 SSH 연결을 설정하여 비밀번호가 필요하지 않은지 확인합니다. 호스트 지문에 문제가 없어야 합니다. 문제가 발생할 경우 ~/.ssh/known_hosts 파일에서 오래된 지문을 제거합니다. 그런 다음 다시 시도하십시오. 지문은 로컬 ~/.ssh/known_hosts 파일에 저장됩니다.

2.3. 마이그레이션 수행

SUSE Manager 4.3에서 SUSE Multi-Linux Manager 5.1로 마이그레이션할 때는 대상 인스턴스가 기존 설정의 사양을 충족하거나 초과하는지 확인해야 합니다.

여기에는 메모리(RAM), CPU 코어, 스토리지 및 네트워크 대역폭이 포함되지만, 이에 국한되지 않습니다.

보안이 강화된 SUSE Multi-Linux Manager 서버 호스트는 /tmp 폴더의 파일 실행을 제한할 수 있습니다. 이러한 경우, 해결 방법으로 mgradm`를 실행하기 전에 `TMPDIR 환경 변수를 다른 기존 경로로 내보내십시오.

예:

export TMPDIR=/path/to/other/tmp

SUSE Multi-Linux Manager 업데이트에서는 이 해결 방법이 불필요하도록 도구가 변경될 예정입니다.

SUSE Manager 4.3에서 마이그레이션할 때 `Password for the CA key to generate`을(를) 입력하라는 메시지가 표시됩니다. SUSE Manager 4.3 설치 시 사용한 동일한 CA 비밀번호를 입력하는 것이 중요합니다.

잘못된 비밀번호를 입력하면 데이터베이스 인증서 생성에 실패하며, 다음과 같은 오류로 마이그레이션이 중단됩니다.

Error: cannot configure db container: Cannot generate database certificate: CA validation failed!

마이그레이션 프로세스를 시작하기 전에 올바른 CA 비밀번호가 준비되어 있는지 확인합니다.
절차 마이그레이션 수행

  1. 이 단계는 선택 사항입니다. 인프라에 사용자 정의 영구 스토리지가 필요한 경우 mgr-storage-server 도구를 사용하십시오. `mgr-storage-server`에 대한 자세한 내용은 installation-and-upgrade:hardware-requirements.adoc#install-hardware-requirements-storage를 참조하십시오.

  2. 다음 명령을 실행하여 새 SUSE Multi-Linux Manager 5.1 서버를 마이그레이션하고 설정합니다. `<oldserver.fqdn>`을(를) 4.3 서버의 FQDN으로 교체합니다:

    마이그레이션 프로세스를 시작하기 전에 4.3 서버를 업그레이드하고 모든 사용 가능한 업데이트를 적용해야 합니다. 또한 전체 마이그레이션 시간을 줄이기 위해 불필요한 채널을 제거하십시오.

    마이그레이션은 복제해야 할 데이터의 양에 따라 매우 오랜 시간이 걸릴 수 있습니다. 작동 중지 시간을 줄이기 위해 레거시 4.3 서버의 모든 서비스가 계속 가동되는 동안 초기 복제, 재복제 또는 최종 복제 및 전환 단계로 마이그레이션을 여러 번 실행할 수 있습니다.

    최종 마이그레이션 중에만 이전 4.3 서버의 프로세스를 중지하면 됩니다.

    최종 복제가 아닌 모든 복제에 대해 이전 4.3 서버의 서비스가 자동으로 중지되지 않도록 매개변수 `--prepare`를 추가합니다.

    실패한 마이그레이션을 다시 실행하면 각 실패한 마이그레이션마다 /var/lib/containers/storage/volumes 내부에 새로운 백업 디렉토리가 생성되어, 이로 인해 대용량의 백업 디렉토리가 누적되어 상당한 공간을 차지하게 됩니다.

    이 백업은 마이그레이션 도구에 의해 자동으로 제거되지 않습니다. 마이그레이션이 실패하면 다음 시도를 위해 충분한 공간이 확보되도록 이전 백업 디렉토리들을 수동으로 검사하고 정리해야 합니다.

    이 공간을 관리하지 못하면 다음 마이그레이션 시도가 실패할 수 있습니다.

    모든 마이그레이션 및 검증이 완료된 후에는 var-pgsql-backup 볼륨을 제거하십시오.

    • --prepare 단계는 최종 마이그레이션이 시작되지 않은 경우에만 여러 번 실행할 수 있습니다.

    • 최종 마이그레이션이 시작되어 데이터베이스 업그레이드 단계에 도달하면 데이터가 손상될 수 있으므로 --prepare 명령을 다시 실행하지 않아야 합니다.

    		 
    mgradm migrate podman <oldserver.fqdn> --prepare
절차 최종 마이그레이션

  1. 4.3 서버에서 SUSE Manager 서비스를 중지합니다.

    spacewalk-service stop

  2. 4.3 서버에서 PostgreSQL 서비스를 중지합니다.

    systemctl stop postgresql

  3. SUSE Multi-Linux Manager 5.1 서버에서 최종 마이그레이션을 수행합니다.

    mgradm migrate podman <oldserver.fqdn>

  4. 신뢰할 수 있는 SSL CA 인증서를 마이그레이션합니다.

2.3.1. 인증서 마이그레이션

RPM의 일부로 설치되어 SUSE Multi-Linux Manager 4.3의 /usr/share/pki/trust/anchors/ 디렉토리에 저장된 신뢰할 수 있는 SSL CA 인증서는 마이그레이션되지 않습니다. SUSE는 컨테이너에 RPM 패키지를 설치하지 않기 때문에, 관리자는 마이그레이션 후 SUSE Manager 4.3 서버에서 이러한 인증서 파일을 수동으로 마이그레이션해야 합니다.

절차 인증서 마이그레이션

  1. SUSE Manager 4.3 서버에서 새 SUSE Multi-Linux Manager 5.1 서버로 파일을 복사합니다. 예를 들어, `/local/ca.file`처럼.

  2. 다음을 사용하여 파일을 컨테이너에 복사합니다.

    mgrctl cp /local/ca.file server:/etc/pki/trust/anchors/

mgradm migrate 명령을 성공적으로 실행한 후에도, 모든 클라이언트의 Salt 설정은 여전히 이전 4.3 서버를 가리킵니다.

5.1 서버로 리디렉션하려면 인프라 수준(DHCP 및 DNS)에서 새 서버의 이름을 4.3 서버와 동일한 FQDN 및 IP 주소로 변경해야 합니다.

최신 버전은 FQDN만 사용하여 서버와 자동으로 다시 연결할 수 있으므로 최신 버전의 미니언이 클라이언트에 설치되어 있다면 IP 주소 조정을 수행하지 않아도 됩니다.

3. 클라이언트 도구 리브랜딩

SUSE Multi-Linux Manager 5.1는 모든 지원되는 운영 체제를 위한 리브랜딩된 클라이언트 도구 세트를 소개합니다. 이 전환은 원활하며, 새로운 제품 동기화를 수행하는 사용자는 업데이트된 채널 이름만 보게 될 것입니다.

SUSE Manager Client Tools for XYZ 4.3 또는 5.0에 이전에 등록된 클라이언트가 사용하던 SUSE Multi-Linux Manager 채널은 버전 5.1에서 더 이상 사용할 수 없으며, 버전 5.1에서는 더 이상 업데이트를 수신하지 않습니다.

이전 채널은 마이그레이션 후에도 기존 고객에게 할당된 상태로 유지되지만, 해당 리포지토리는 제거되었습니다.

지속적인 업데이트를 보장하기 위해 사용자는 다음을 수행해야 합니다.

  • 관련 제품에 대한 새로운 SUSE Multi-Linux Manager Client Tools for XYZ 채널을 미러링하고 적절한 클라이언트에 할당하십시오.

  • 구식 SUSE Manager Client Tools for XYZ 채널을 할당 해제하십시오.

이는 또한 기존 클라이언트 도구를 기반으로 한 모든 CLM 프로젝트도 이에 맞춰 조정되어야 함을 의미합니다.

예제 워크플로우는 Switch to new client tools channels를 참조하십시오.