Microsoft Azure에서 RHEL 배포 및 관리


Red Hat Enterprise Linux 10

Azure에서 RHEL 시스템 이미지 가져오기 및 RHEL 인스턴스 생성

Red Hat Customer Content Services

초록

Microsoft Azure에서 RHEL(Red Hat Enterprise Linux)을 사용하려면 RHEL 시스템 이미지를 생성하고 배포할 수 있습니다.
여기에는 다음이 포함됩니다.
  • Azure에서 RHEL 이미지 등록, 배포 및 프로비저닝
  • RHEL Azure VM(가상 머신)의 네트워킹 구성 관리
  • 플랫폼 보안 및 신뢰할 수 있는 실행 기술 구성
  • RHEL 인스턴스의 HA(Red Hat High Availability) 클러스터 관리

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

Jira를 통해 피드백 제출 (계정 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 바에서 생성을 클릭합니다.
  3. 요약 필드에 설명 제목을 입력합니다.
  4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. 퍼블릭 클라우드 플랫폼에 RHEL 소개

퍼블릭 클라우드 플랫폼은 컴퓨팅 리소스를 서비스로 제공합니다. 온프레미스 하드웨어를 사용하는 대신 RHEL(Red Hat Enterprise Linux) 시스템을 퍼블릭 클라우드 인스턴스로 포함한 IT 워크로드를 실행할 수 있습니다.

1.1. 퍼블릭 클라우드에서 RHEL을 사용할 때의 이점

퍼블릭 클라우드 플랫폼에 있는 클라우드 인스턴스로 RHEL은 온프레미스 물리적 시스템 또는 VM(가상 머신)에 비해 다음과 같은 이점이 있습니다.

유연하고 세분화된 리소스 할당

RHEL의 클라우드 인스턴스는 클라우드 플랫폼에서 VM으로 실행되므로 클라우드 서비스 공급자가 관리하는 원격 서버 클러스터입니다. 따라서 소프트웨어 수준에서 인스턴스에 하드웨어 리소스를 할당하는 것은 특정 유형의 CPU 또는 스토리지와 같이 쉽게 사용자 지정할 수 있습니다.

로컬 RHEL 시스템과 비교하여 물리적 호스트의 기능에 의해 제한되지도 않습니다. 대신 클라우드 공급자가 제공하는 선택 사항에 따라 다양한 기능을 선택할 수 있습니다.

공간 및 비용 효율성

클라우드 워크로드를 호스팅하기 위해 온프레미스 서버를 소유할 필요가 없습니다. 이렇게 하면 물리적 하드웨어와 관련된 공간, 전원 및 유지 관리 요구 사항을 방지할 수 있습니다.

대신, 퍼블릭 클라우드 플랫폼에서는 클라우드 인스턴스를 사용하기 위해 클라우드 공급자를 직접 지불합니다. 비용은 일반적으로 인스턴스에 할당된 하드웨어 및 이를 사용하는 시간을 기반으로 합니다. 따라서 요구 사항에 따라 비용을 최적화할 수 있습니다.

소프트웨어 제어 구성

클라우드 인스턴스의 전체 구성을 클라우드 플랫폼에서 데이터로 저장하고 소프트웨어로 제어합니다. 따라서 인스턴스를 쉽게 생성, 제거, 복제 또는 마이그레이션할 수 있습니다. 또한 클라우드 공급자 콘솔에서 원격으로 클라우드 인스턴스를 운영하고 기본적으로 원격 스토리지에 연결합니다.

또한 언제든지 클라우드 인스턴스의 현재 상태를 스냅샷으로 백업할 수 있습니다. 나중에 스냅샷을 로드하여 인스턴스를 저장된 상태로 복원할 수 있습니다.

호스트 및 소프트웨어 호환성 분리

로컬 VM과 유사하게 클라우드 인스턴스의 RHEL 게스트 운영 체제는 KVM(커널 기반 가상 머신)에서 실행됩니다. 이 커널은 호스트 운영 체제와 인스턴스에 연결하는 데 사용하는 클라이언트 시스템과 다릅니다.

따라서 클라우드 인스턴스에 모든 운영 체제를 설치할 수 있습니다. 즉, RHEL 퍼블릭 클라우드 인스턴스에서 로컬 운영 체제에서 사용할 수 없는 RHEL별 애플리케이션을 실행할 수 있습니다.

또한 인스턴스의 운영 체제가 불안정하거나 손상된 경우에도 클라이언트 시스템에 영향을 미치지 않습니다.

1.2. RHEL의 퍼블릭 클라우드 사용 사례

퍼블릭 클라우드에 배포하면 많은 이점이 있지만 모든 시나리오에서 가장 효율적인 솔루션은 아닙니다. RHEL 배포를 퍼블릭 클라우드로 마이그레이션할지 여부를 평가하고 있는 경우 사용 사례가 퍼블릭 클라우드의 이점을 활용할지 여부를 고려하십시오.

유용한 사용 사례
  • 퍼블릭 클라우드 인스턴스 배포는 배포의 활성 컴퓨팅 성능을 유연하게 늘리고 줄이는 데 매우 효과적이며 확장 및 축소 라고도 합니다. 따라서 다음 시나리오에서 퍼블릭 클라우드에서 RHEL을 사용할 수 있습니다.

    • 최대 워크로드 및 낮은 일반 성능 요구 사항이 있는 클러스터입니다. 필요에 따라 확장 및 축소하면 리소스 비용 측면에서 매우 효율적일 수 있습니다.
    • 클러스터를 신속하게 설정하거나 확장합니다. 이렇게 하면 로컬 서버를 설정하는 데 드는 초기 비용이 발생하지 않습니다.
  • 로컬 환경에서 발생하는 작업은 클라우드 인스턴스에 영향을 미치지 않습니다. 따라서 백업 및 재해 복구에 사용할 수 있습니다.
잠재적으로 문제가 있는 사용 사례
  • 조정할 수 없는 기존 환경을 실행하고 있습니다. 기존 배포의 특정 요구에 맞게 클라우드 인스턴스를 사용자 정의하는 것은 현재 호스트 플랫폼과 비교하여 경제적으로 효율적이지 않을 수 있습니다.
  • 예산에 하드 제한으로 작업하고 있습니다. 로컬 데이터 센터에서 배포를 유지 관리하면 일반적으로 퍼블릭 클라우드보다 유연성이 떨어지지만 최대 리소스 비용을 제어할 수 있습니다.

퍼블릭 클라우드 배포를 위해 RHEL을 가져오는 방법에 대한 자세한 내용은 퍼블릭 클라우드 배포를 위한 RHEL 가져오기 를 참조하십시오.

1.3. 퍼블릭 클라우드로 마이그레이션할 때 빈번한 우려 사항

RHEL 워크로드를 로컬 환경에서 퍼블릭 클라우드 플랫폼으로 이동하면 변경 사항에 대한 우려가 발생할 수 있습니다. 다음은 가장 일반적으로 묻는 질문입니다.

RHEL이 로컬 가상 머신과 다른 방식으로 작동합니까?

대부분의 경우 퍼블릭 클라우드 플랫폼의 RHEL 인스턴스는 온프레미스 서버와 같은 로컬 호스트의 RHEL 가상 머신과 동일하게 작동합니다. 주요 예외 사항은 다음과 같습니다.

  • 퍼블릭 클라우드 인스턴스는 프라이빗 오케스트레이션 인터페이스 대신 클라우드 리소스를 관리하기 위해 공급자별 콘솔 인터페이스를 사용합니다.
  • 중첩된 가상화와 같은 특정 기능이 제대로 작동하지 않을 수 있습니다. 배포에 특정 기능이 중요한 경우 선택한 퍼블릭 클라우드 공급자와 사전에 기능의 호환성을 확인하십시오.
내 데이터가 로컬 서버와 달리 퍼블릭 클라우드에서 안전하게 유지됩니까?

RHEL 클라우드 인스턴스의 데이터는 소유권에 있으며 퍼블릭 클라우드 공급자는 이에 액세스할 수 없습니다. 또한 주요 클라우드 공급자는 전송 시 데이터 암호화를 지원하므로 가상 머신을 퍼블릭 클라우드로 마이그레이션할 때 데이터의 보안이 향상됩니다.

RHEL 퍼블릭 클라우드 인스턴스의 보안 측면에서는 다음이 적용됩니다.

  • 클라우드 하이퍼바이저의 보안을 담당하는 퍼블릭 클라우드 공급자
  • Red Hat은 인스턴스의 RHEL 게스트 운영 체제의 보안 기능을 제공합니다.
  • 클라우드 인프라의 특정 보안 설정 및 관행을 관리합니다.
내 지역이 RHEL 퍼블릭 클라우드 인스턴스의 기능에 미치는 영향은 무엇입니까?
지리적 위치에 관계없이 퍼블릭 클라우드 플랫폼에서 RHEL 인스턴스를 사용할 수 있습니다. 따라서 온-프레미스 서버와 동일한 리전의 인스턴스를 실행할 수 있습니다. 그러나 물리적으로 멀리 있는 지역에 인스턴스를 호스트하면 작동 시 대기 시간이 길어질 수 있습니다. 또한 퍼블릭 클라우드 공급자에 따라 특정 리전에서 추가 기능을 제공하거나 비용 효율성을 높일 수 있습니다. RHEL 인스턴스를 만들기 전에 선택한 클라우드 공급자에 사용할 수 있는 호스팅 리전의 속성을 검토하십시오.

1.4. 퍼블릭 클라우드 배포를 위한 RHEL 가져오기

퍼블릭 클라우드 환경에 RHEL 시스템을 배포하려면 다음을 수행해야 합니다.

1.5. RHEL 클라우드 인스턴스 생성 방법

퍼블릭 클라우드 플랫폼에 RHEL 인스턴스를 배포하려면 다음 방법 중 하나를 사용할 수 있습니다.

RHEL 시스템 이미지를 생성하여 클라우드 플랫폼으로 가져옵니다.
  • 시스템 이미지를 생성하려면 RHEL 이미지 빌더를 사용하거나 이미지를 수동으로 빌드할 수 있습니다.
  • 이 방법은 기존 RHEL 서브스크립션을 사용하며 BYOOS(사용자 서브스크립션 )라고도 합니다.
  • 연간 서브스크립션 비용을 미리 지불하면 Red Hat 고객 할인 혜택을 누릴 수 있습니다.
  • Red Hat은 고객 서비스를 제공합니다.
  • 효과적으로 많은 이미지를 생성하기 위해 cloud-init 툴을 사용할 수 있습니다.
클라우드 공급자 마켓플레이스에서 직접 RHEL 인스턴스를 구입
  • 서비스 사용에 대한 시간당 요금을 지불하십시오. 따라서,이 방법은 또한 지불 (PAYG)이라고합니다.
  • 클라우드 플랫폼 공급자는 고객 서비스를 제공합니다.
참고

Microsoft Azure에서 RHEL 인스턴스를 배포하는 다양한 방법을 사용하는 방법에 대한 자세한 내용은 이 문서의 다음 장을 참조하십시오.

2장. Microsoft Azure에 VHD 이미지 준비 및 업로드

RHEL 이미지 빌더를 사용하여 사용자 지정 이미지를 생성하고 Microsoft Azure 클라우드에서 수동으로 또는 자동으로 업데이트할 수 있습니다.

2.1. Microsoft Azure VHD 이미지를 수동으로 업로드 준비

Microsoft Azure 클라우드에 수동으로 업로드할 수 있는 VHD 이미지를 생성하려면 RHEL 이미지 빌더를 사용할 수 있습니다.

사전 요구 사항

  • Microsoft Azure 리소스 그룹 및 스토리지 계정이 있어야 합니다.
  • Python이 설치되어 있어야 합니다. AZ CLI 툴은 Python에 따라 다릅니다.

프로세스

  1. Microsoft 리포지토리 키를 가져옵니다.

    $ sudo rpm --import https://packages.microsoft.com/keys/microsoft-2025.asc
    Copy to Clipboard Toggle word wrap
  2. packages-microsoft-com-prod 리포지토리를 생성합니다.

    [azure-cli]
    name=Azure CLI
    baseurl=https://packages.microsoft.com/yumrepos/packages.microsoft.com/rhel/10/prod/
    enabled=1
    gpgcheck=1
    gpgkey=https://packages.microsoft.com/keys/microsoft.asc
    Copy to Clipboard Toggle word wrap
  3. Microsoft Azure CLI를 설치합니다. Microsoft Azure CLI 패키지의 다운로드된 버전은 현재 사용 가능한 버전에 따라 다를 수 있습니다.

    $ sudo dnf install azure-cli
    Copy to Clipboard Toggle word wrap
  4. Run Microsoft Azure CLI:

    $ az login
    Copy to Clipboard Toggle word wrap

    터미널에는 다음 메시지가 표시됩니다. 참고, 로그인할 수 있도록 브라우저를 시작했습니다. 장치 코드에 대한 이전 환경의 경우 az login --use-device-code 를 사용합니다. 그런 다음 터미널에서 로그인 할 수 있는 위치에서 로그인을 엽니다.

    참고

    원격(SSH) 세션을 실행하는 경우 브라우저에서 로그인 페이지 링크가 열려 있지 않습니다. 이 경우 브라우저에 대한 링크를 복사하고 로그인하여 원격 세션을 인증할 수 있습니다. 로그인하려면 웹 브라우저를 사용하여 로그인 페이지를 열고 인증할 장치 코드를 입력합니다.

  5. Microsoft Azure의 스토리지 계정 키를 나열하고 이전 명령의 출력에서 key1 값을 기록합니다.

    $ az storage account keys list --resource-group <resource_group_name> --account-name <account_name>
    Copy to Clipboard Toggle word wrap

    resource-group-name 을 Microsoft Azure 리소스 그룹의 이름으로 바꾸고 storage-account-name 을 Microsoft Azure 스토리지 계정 이름으로 교체합니다.

    1. 다음 명령을 사용하여 사용 가능한 리소스를 나열하려면 다음을 수행합니다.

      $ az resource list
      Copy to Clipboard Toggle word wrap
  6. 스토리지 컨테이너를 생성합니다.

    $ az storage container create --account-name <storage_account_name> \
    --account-key <key1_value> --name <storage_account_name>
    Copy to Clipboard Toggle word wrap

    storage-account-name 을 스토리지 계정 이름으로 교체합니다.

2.2. Microsoft Azure 클라우드에 VHD 이미지를 수동으로 업로드

사용자 지정 VHD 이미지를 생성한 후 Microsoft Azure 클라우드에 수동으로 업로드할 수 있습니다. CLI를 사용하여 .vhd 이미지를 생성할 때 RHEL 이미지 빌더는 /var 하위 디렉터리에 임시 파일을 작성합니다.

.vhd 이미지 생성이 실패하지 않도록 /var 하위 디렉토리 용량을 15~20GB 이상의 여유 공간으로 늘리십시오.

사전 요구 사항

  • Microsoft Azure VHD 이미지를 업로드하려면 시스템을 설정해야 합니다.
  • RHEL 이미지 빌더에서 생성한 Microsoft Azure VHD 이미지가 있어야 합니다.

    • GUI에서 Azure Disk Image (.vhd) 이미지 유형을 사용합니다.
    • CLI에서 vhd 출력 유형을 사용합니다.

프로세스

  1. 이미지를 빌드합니다.

    $ image-builder build <image-type>
    Copy to Clipboard Toggle word wrap
  2. 이미지를 Microsoft Azure에 푸시하고 해당 이미지에서 인스턴스를 생성합니다.

    $ az storage blob upload --account-name account_name --container-name container_name --file image_disk.vhd --name image-disk.vhd --type page
    Copy to Clipboard Toggle word wrap
  3. Microsoft Azure Blob 스토리지에 업로드한 후 Microsoft Azure 이미지를 생성합니다. RHEL 이미지 빌더를 사용하여 생성한 이미지는 V1 = BIOSV2 = UEFI 인스턴스 유형을 모두 지원하는 하이브리드 이미지를 생성하므로 --hyper-v-generation 인수를 지정할 수 있습니다. 기본 인스턴스 유형은 V1 입니다.

    $ az image create --resource-group resource_group_name --name image-disk.vhd --os-type linux --location location \
    --source https://$account_name.blob.core.windows.net/container_name/image-disk.vhd
    - Running
    Copy to Clipboard Toggle word wrap

검증

  1. Microsoft Azure 포털을 사용하여 인스턴스 또는 다음과 유사한 명령을 생성합니다.

    $ az vm create --resource-group resource_group_name --location location --name vm_name --image image-disk.vhd(--admin-username azure-user --generate-ssh-keys*
    - Running
    Copy to Clipboard Toggle word wrap
  2. SSH를 사용하여 결과 인스턴스에 액세스하여 개인 키를 사용합니다. azure-user 로 로그인합니다. 이 사용자 이름은 이전 단계에서 설정되었습니다.

2.3. Microsoft Azure 클라우드에 VHD 이미지 생성 및 자동 업로드

RHEL 이미지 빌더를 사용하면 Microsoft Azure Cloud 서비스 공급자의 Azure Blob 스토리지에 자동으로 업로드되는 .vhd 이미지를 생성할 수 있습니다.

사전 요구 사항

프로세스

  1. RHEL 이미지 빌더 대시보드에서 사용하려는 블루프린트를 선택합니다.
  2. 이미지 탭을 클릭합니다.
  3. Create Image 를 클릭하여 사용자 지정 .vhd 이미지를 만듭니다.

    이미지 생성 마법사가 열립니다.

    1. 유형 드롭다운 메뉴 목록에서 Microsoft Azure (.vhd) 를 선택합니다.
    2. 이미지를 Microsoft Azure Cloud에 업로드하려면 Azure에 업로드 확인란을 선택합니다.
    3. 이미지 크기를 입력하고 다음을 클릭합니다.
  4. Azure에 업로드 페이지에서 다음 정보를 입력합니다.

    1. 인증 페이지에서 다음을 입력합니다.

      1. 스토리지 계정 이름입니다. Microsoft Azure 포털스토리지 계정 페이지에서 찾을 수 있습니다.
      2. 스토리지 액세스 키: 액세스 키 스토리지 페이지에서 찾을 수 있습니다.
      3. 다음을 클릭합니다.
    2. 인증 페이지에서 다음을 입력합니다.

      1. 이미지 이름입니다.
      2. 스토리지 컨테이너 입니다. 이미지를 업로드할 Blob 컨테이너입니다. Microsoft Azure 포털에서 Blob 서비스 섹션에서 찾습니다.
      3. 다음을 클릭합니다.
  5. 검토 페이지에서 생성 을 클릭합니다. RHEL 이미지 빌더 및 업로드 프로세스가 시작됩니다.

    Microsoft Azure Cloud 에 내보낸 이미지에 액세스합니다.

  6. Microsoft Azure 포털에 액세스합니다.
  7. 검색 모음에서 "스토리지 계정"을 입력하고 목록에서 스토리지 계정을 클릭합니다.
  8. 검색 모음에서 "Images"를 입력하고 Services 아래에서 첫 번째 항목을 선택합니다. 이미지 대시보드 로 리디렉션됩니다.
  9. 탐색 패널에서 컨테이너를 클릭합니다.
  10. 생성한 컨테이너를 찾습니다. 컨테이너 내부에서는 RHEL 이미지 빌더를 사용하여 생성하고 푸시한 .vhd 파일입니다.

검증

  1. VM 이미지를 생성하고 시작할 수 있는지 확인합니다.

    1. 검색 모음에서 이미지 계정을 입력하고 목록에서 이미지를 클릭합니다.
    2. +Create 를 클릭합니다.
    3. 드롭다운 목록에서 이전에 사용한 리소스 그룹을 선택합니다.
    4. 이미지의 이름을 입력합니다.
    5. OS 유형에 대해 Linux 를 선택합니다.
    6. VM 생성에 대해 Gen 2 를 선택합니다.
    7. 스토리지 Blob 에서 VHD 파일에 도달할 때까지 찾아보기 를 클릭하고 스토리지 계정 및 컨테이너를 클릭합니다.
    8. 페이지 끝에 있는 Select 를 클릭합니다.
    9. 계정 유형을 선택합니다(예: Standard SSD ).
    10. 검토 + 생성을 클릭한 다음 생성을 클릭합니다. 이미지 생성을 위해 잠시 기다립니다.
  2. VM을 시작하려면 단계를 따르십시오.

    1. 리소스로 이동을 클릭합니다.
    2. 헤더의 메뉴 표시줄에서 + Create VM 을 클릭합니다.
    3. 가상 머신의 이름을 입력합니다.
    4. 크기관리자 계정 섹션을 완료합니다.
    5. 검토 + 생성을 클릭한 다음 생성을 클릭합니다. 배포 진행 상황을 확인할 수 있습니다.

      배포가 완료되면 가상 시스템 이름을 클릭하여 SSH를 사용하여 연결할 인스턴스의 공용 IP 주소를 검색합니다.

    6. 터미널을 열어 VM에 연결할 SSH 연결을 생성합니다.

3장. Azure에서 RHEL 이미지를 컴퓨팅 인스턴스로 배포

Microsoft Azure에서 RHEL 이미지를 사용하려면 이미지를 Azure 호환 형식으로 변환하고 이미지에서 VM을 배포하여 Azure Compute VM으로 실행합니다. RHEL VHD(가상 하드 드라이브)를 Azure 디스크 이미지 형식으로 생성, 사용자 정의 및 배포하려면 다음 방법 중 하나를 사용할 수 있습니다.

  • RHEL 이미지 빌더를 사용합니다. 자세한 내용은 Microsoft Azure에 VHD 이미지 준비 및 업로드를 참조하십시오.
  • VHD를 수동으로 생성하고 구성합니다. 이는 더 복잡한 프로세스이지만 더 세분화된 사용자 지정 옵션을 제공합니다. 자세한 내용은 다음 섹션을 참조하십시오.

시작하기 전에 다음 단계를 완료해야 합니다.

3.1. 퍼블릭 클라우드에 사용 가능한 RHEL 이미지 유형

인증된 클라우드 서비스 공급자(CCSP)에 RHEL 가상 머신 VM을 배포하려면 여러 옵션을 사용할 수 있습니다. 다음 표에는 이미지 유형에 사용할 수 있는 이미지 유형, 서브스크립션, 고려 사항 및 샘플 시나리오가 나열되어 있습니다.

참고

사용자 지정 ISO 이미지를 배포하려면 RHEL 이미지 빌더를 사용할 수 있습니다. RHEL 이미지 빌더를 사용하면 선택한 CCSP와 관련된 사용자 정의 이미지를 생성, 업로드 및 배포할 수 있습니다. 자세한 내용은 사용자 지정된 RHEL 시스템 이미지 구성을 참조하십시오.

Expand
표 3.1. 이미지 옵션
이미지 유형서브스크립션고려 사항샘플 시나리오

Red Hat gold 이미지 배포

기존 Red Hat 서브스크립션 사용

서브스크립션에는 Red Hat 제품 비용 및 Cloud Access 이미지에 대한 지원이 포함되며 다른 모든 인스턴스 비용에 대해 CCSP를 지불합니다.

CCSP에서 Red Hat Gold 이미지를 선택합니다. 골드 이미지와 CCSP에서 액세스하는 방법에 대한 자세한 내용은 Red Hat Cloud Access 참조 가이드를 참조하십시오.

CCSP로 이동하는 사용자 정의 이미지 배포

기존 Red Hat 서브스크립션 사용

서브스크립션에는 사용자 정의 RHEL 이미지에 대한 Red Hat 제품 비용 및 지원이 포함되며 다른 모든 인스턴스 비용에 대해 CCSP를 지불합니다.

사용자 정의 이미지 업로드 및 서브스크립션 연결

기존 RHEL 기반 사용자 정의 머신 이미지 배포

사용자 정의 머신 이미지에는 RHEL 이미지가 포함되어 있습니다.

사용량에 따라 CCSP를 시간별로 지불합니다. 이 모델의 경우 CCSP Marketplace에서 온디맨드 이미지를 사용할 수 있습니다. CCSP는 이러한 이미지를 지원하며 Red Hat은 업데이트를 처리합니다. CCSP는 RHUI(Red Hat Update Infrastructure)를 통해 업데이트를 제공합니다.

CCSP 클라우드 관리 콘솔에서 인스턴스를 시작할 때 RHEL 이미지를 선택하거나 CCSP 시장에서 이미지를 선택합니다.

중요

온디맨드 인스턴스를 사용자 지정 RHEL 인스턴스로 변환할 수 없습니다. 온디맨드 이미지에서 사용자 지정 RHEL로 마이그레이션하려면 고유한 서브스크립션(BYOS) 이미지를 가져오십시오.

  • 새 사용자 지정 RHEL 인스턴스를 만든 다음 온디맨드 인스턴스에서 데이터를 마이그레이션합니다.
  • 데이터 마이그레이션을 완료하면 추가 청구를 방지하기 위해 온디맨드 인스턴스를 종료합니다.

3.2. 필수 시스템 패키지

RHEL의 기본 이미지를 생성하고 구성하려면 호스트 시스템에 다음 패키지가 설치되어 있어야 합니다.

Expand
표 3.2. 시스템 패키지
패키지리포지터리설명

libvirt

rhel-10-for-x86_64-appstream-rpms

플랫폼 가상화 관리를 위한 오픈 소스 API, 데몬 및 관리 도구

virt-install

rhel-10-for-x86_64-appstream-rpms

가상 머신 구축을 위한 명령줄 유틸리티

libguestfs

rhel-10-for-x86_64-appstream-rpms

가상 머신 파일 시스템 액세스 및 수정을 위한 라이브러리

guestfs-tools

rhel-10-for-x86_64-appstream-rpms

VM용 시스템 관리 도구; virt-customize 유틸리티 포함

언급된 시스템 패키지의 설치를 확인하여 사용자 정의 기본 이미지를 사용하여 RHEL 인스턴스 배포의 배포 단계를 수행할 수 있습니다.

3.3. 사용자 정의 기본 이미지를 사용하여 RHEL 인스턴스 배포

VM(가상 머신)을 수동으로 구성하려면 먼저 기본(시작자) 이미지를 생성합니다. 다음으로 구성 설정을 수정하고 VM이 클라우드에서 작동하는 데 필요한 패키지를 추가할 수 있습니다. 이미지를 업로드한 후 특정 애플리케이션에 대한 추가 구성을 변경할 수도 있습니다.

RHEL의 클라우드 이미지를 준비하려면 아래 섹션의 지침을 따르십시오. RHEL의 Hyper-V 클라우드 이미지를 준비하려면 Hyper-V Manager에서 Red Hat 기반 가상 머신 준비를 참조하십시오.

기본 이미지에서 VM을 생성하면 다음과 같은 이점이 있습니다.

  • 완전히 사용자 정의 가능
  • 모든 사용 사례에서 높은 유연성
  • 경량 - 운영 체제와 필요한 런타임 라이브러리만 포함합니다.

ISO 이미지에서 RHEL의 사용자 정의 기본 이미지를 생성하려면 CLI(명령줄 인터페이스) 또는 웹 콘솔을 사용하여 VM을 생성하고 구성할 수 있습니다.

참고

다음 VM 구성을 확인합니다.

설정은 초기 VM 생성 중 또는 VM 이미지를 Azure 클라우드에 확인하는 동안 활성화됩니다.

  • SSH - SSH를 활성화하여 VM에 대한 원격 액세스 권한을 부여합니다.
  • DHCP - DHCP를 사용하도록 기본 가상 어댑터를 구성합니다.
  • 스왑 공간 - 설치 중에 운영 체제(OS) 디스크 또는 스토리지 디스크에 전용 스왑 파일 또는 스왑 파티션을 생성하지 마십시오. VM의 임시 디스크에 스왑 파티션을 자동으로 생성하도록 cloud-init 유틸리티를 구성합니다. 임시 디스크는 VM의 로컬 스토리지이며 리소스 디스크는 VM 자체에 마운트됩니다. 두 스토리지 유형 모두 데이터를 일시적으로 저장합니다.
  • NIC - 기본 가상 네트워크 어댑터로 virtio를 선택합니다.
  • Encryption - 사용자 정의 이미지의 경우 Azure에서 전체 디스크 암호화에 NBDE(Network Bound Disk Encryption)를 사용합니다.

사전 요구 사항

  • 시스템 패키지 필수 목록을 확인했습니다.
  • 호스트 시스템에서 가상화를 활성화했습니다.
  • 웹 콘솔의 경우 다음 옵션을 확인하십시오.
  • Immediately Start VM 옵션을 선택하지 않았습니다.
  • 메모리 크기를 원하는 설정으로 이미 변경했습니다.
  • 가상 네트워크 인터페이스 설정에서 모델 옵션을 virtio 로 변경하고 vCPU 를 VM의 용량 설정으로 변경했습니다.

프로세스

  1. RHEL(Red Hat Enterprise Linux) VM을 구성합니다.

    1. CLI(명령줄)에서 설치하려면 VM의 요구 사항에 따라 기본 메모리, 네트워크 인터페이스 및 CPU를 설정해야 합니다. 자세한 내용은 명령줄을 사용하여 가상 머신 생성을참조하십시오.
    2. 웹 콘솔에서 설치하려면 웹 콘솔을 사용하여 가상 머신 생성을참조하십시오.
  2. 설치가 시작되면 다음을 수행합니다.

    1. root 암호를 만듭니다.
    2. 관리자 사용자 계정을 생성합니다.
  3. 설치가 완료되면 VM을 재부팅하고 root 계정에 로그인합니다.
  4. root 로 로그인한 후 이미지를 구성할 수 있습니다.
  5. VM을 등록하고 RHEL 리포지토리를 활성화합니다.

    # subscription-manager register
    Copy to Clipboard Toggle word wrap

검증

  • 시스템에 cloud-init 패키지가 있는지 확인하고 활성화합니다.

    # dnf install cloud-init
    # systemctl enable --now cloud-init.service
    Copy to Clipboard Toggle word wrap
  • VM의 전원을 끕니다.

다음 단계

  • Azure CLI를 설치하여 Azure 리소스 및 서비스에 액세스합니다.

3.4. Azure CLI 설치

Azure CLI(명령줄 인터페이스)를 사용하여 Azure Cloud에 연결하고 호스트 터미널에서 직접 Azure 리소스를 관리할 수 있습니다.

사전 요구 사항

프로세스

  1. Microsoft 리포지토리 키를 가져옵니다.

    $ sudo dnf --import https://packages.microsoft.com/keys/microsoft.asc
    Copy to Clipboard Toggle word wrap
  2. 로컬 Azure CLI 리포지토리 항목을 생성합니다.

    $ sudo sh -c 'echo -e "[azure-cli]\nname=Azure CLI\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/azure-cli.repo'
    Copy to Clipboard Toggle word wrap
  3. dnf 패키지 인덱스를 업데이트합니다.

    $ sudo dnf update
    Copy to Clipboard Toggle word wrap
  4. Azure CLI를 설치합니다.

    $ sudo dnf install -y azure-cli
    Copy to Clipboard Toggle word wrap
  5. Azure CLI를 실행합니다.

    $ az login
    Copy to Clipboard Toggle word wrap

다음 단계

3.5. Hyper-V 장치 드라이버 설치

Microsoft는 Hyper-V 패키지에 대한 LIS(Linux Integration Services)의 일부로 네트워크 및 스토리지 장치 드라이버를 제공합니다. VM 이미지를 Azure VM으로 프로비저닝하기 전에 Hyper-V 장치 드라이버를 설치합니다.

사전 요구 사항

프로세스

  1. 시스템에 Hyper-V 장치 드라이버가 있는지 확인합니다.

    # lsinitrd | grep hv
    
    drwxr-xr-x   2 root     root            0 Aug 12 14:21 usr/lib/modules/3.10.0-932.el10.x86_64/kernel/drivers/hv
    -rw-r--r--   1 root     root        31272 Aug 11 08:45 usr/lib/modules/3.10.0-932.el10.x86_64/kernel/drivers/hv/hv_vmbus.ko.xz
    -rw-r--r--   1 root     root        25132 Aug 11 08:46 usr/lib/modules/3.10.0-932.el10.x86_64/kernel/drivers/net/hyperv/hv_netvsc.ko.xz
    -rw-r--r--   1 root     root         9796 Aug 11 08:45 usr/lib/modules/3.10.0-932.el10.x86_64/kernel/drivers/scsi/hv_storvsc.ko.xz
    Copy to Clipboard Toggle word wrap

    모든 드라이버가 설치되지 않았거나 hv_vmbus 드라이버가 나열되는 경우 나머지 단계를 완료합니다.

  2. /etc/dracut.conf.d 디렉토리에 hv.conf 파일을 생성하고 다음 드라이버 매개변수를 추가합니다.

    # vi hv.conf
    
    add_drivers+=" hv_vmbus "
    add_drivers+=" hv_netvsc "
    add_drivers+=" hv_storvsc "
    add_drivers+=" nvme "
    Copy to Clipboard Toggle word wrap

    환경에 다른 Hyper-V 드라이버가 이미 존재하는 경우 특수 드라이버를 로드하기 위해 큰따옴표 add_drivers+=" hv_vmbus" 뒤에 공백을 추가해야 합니다.

  3. initramfs 이미지를 다시 생성합니다.

    # dracut -f -v --regenerate-all
    Copy to Clipboard Toggle word wrap

검증

  1. 시스템을 재부팅합니다.
  2. 드라이버 설치를 확인합니다.

    # lsinitrd | grep hv
    Copy to Clipboard Toggle word wrap

다음 단계

3.6. Azure에서 cloud-init로 스왑 공간 구성

Microsoft Azure에서 RHEL(Red Hat Enterprise Linux) 가상 머신(VM)에 스왑 공간을 사용하려면 임시 디스크에 스왑 파티션을 생성해야 합니다. 운영 체제 디스크 또는 데이터(스토리지) 디스크가 아닌 스왑 파티션을 만드는 데 임시 디스크만 사용하십시오. 가상 머신이 삭제될 때 임시 디스크도 삭제되므로 스왑 파티션도 제거됩니다.

cloud-init 유틸리티를 사용하여 필요에 따라 임시 디스크에 스왑 파티션을 구성할 수 있습니다. 임시 디스크는 VM의 로컬 스토리지이며 리소스 디스크는 VM 자체에 마운트됩니다. 두 스토리지 유형 모두 데이터를 일시적으로 저장합니다. VM의 삭제, 이동, 중지 또는 실패로 인해 임시 또는 리소스 디스크에 저장된 데이터가 손실됩니다.

중요

영구 데이터에는 임시 디스크를 사용하지 마십시오. 스왑 파티션을 포함한 모든 콘텐츠는 VM을 중지하거나 이동할 때 삭제됩니다.

사전 요구 사항

  • VM에 cloud-init 유틸리티를 설치했습니다.
  • /etc/waagent.conf 파일에서 매개변수를 설정하여 Windows Azure Linux Agent(WALA)에서 스왑 구성을 비활성화했습니다.

    ResourceDisk.Format=n
    ResourceDisk.EnableSwap=n
    ResourceDisk.SwapSizeMB=0
    Copy to Clipboard Toggle word wrap
  • VM에 임시 디스크를 사용할 수 있습니다.

프로세스

  1. VM에 로그인합니다.
  2. /etc/cloud/cloud.cfg.d/00-azure-swap.cfg 구성 파일을 생성하고 편집하고 다음 cloud-init 구성을 파일에 추가합니다.

    # vi /etc/cloud/cloud.cfg.d/00-azure-swap.cfg
    Copy to Clipboard Toggle word wrap
    #cloud-config
    disk_setup:
      ephemeral0:
        table_type: gpt
        layout: [66, [33,82]]
        overwrite: true
    fs_setup:
      - device: ephemeral0.1
        filesystem: ext4
      - device: ephemeral0.2
        filesystem: swap
    mounts:
      - ["ephemeral0.1", "/mnt"]
      - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service", "0", "0"]
    Copy to Clipboard Toggle word wrap

    이 구성:

    • 임시 디스크(ephemeral0)를 GPT 파티션 테이블로 분할합니다.
    • 두 개의 파티션을 생성합니다. 파일 시스템의 경우 66%( /mnt에 마운트됨)와 스왑 공간의 경우 33%입니다.
    • 첫 번째 파티션을 ext4 로 포맷하고 두 번째 파티션을 스왑 으로 포맷합니다.
    • 부팅 시 두 파티션 자동 마운트를 구성합니다.

      참고

      파티션 레이아웃 [66, [33,82]] 은 디스크의 66%를 첫 번째 파티션에 할당하고 33%를 두 번째 파티션에 할당합니다. 두 번째 파티션 사양의 82 는 Linux 스왑 파티션 유형을 나타냅니다. 요구 사항에 따라 이러한 백분율을 조정할 수 있습니다.

  3. 구성 파일에 오류가 있는지 확인합니다.

    # cloud-init devel schema --config-file /etc/cloud/cloud.cfg.d/00-azure-swap.cfg
    Copy to Clipboard Toggle word wrap

    구성이 유효한 경우 명령에서 오류를 반환하지 않습니다.

검증

  • VM을 재부팅한 후 /etc/fstab 파일의 활성 스왑 공간, 스왑 사용량 및 스왑 파티션 항목을 확인하여 스왑 파티션이 구성되어 활성화되었는지 확인합니다.

    • 활성 스왑 공간을 확인합니다.

      $ swapon -s
      Copy to Clipboard Toggle word wrap

      출력에 ephemeral0.2 의 스왑 파티션이 표시되어야 합니다.

      Filename                 Type        Size      Used    Priority
      /dev/ephemeral0.2     partition     8388604     0      -2
      Copy to Clipboard Toggle word wrap
    • 스왑 사용량을 확인합니다.

      $ free -h
      Copy to Clipboard Toggle word wrap

      출력에는 스왑 행에 스왑 공간이 표시되어야 합니다.

               total        used        free      shared      buffered/cache   available
      Mem:     7.8Gi        1.2Gi       5.8Gi        16MiB       800MiB       6.3Gi
      Swap:    8.0Gi        0B          8.0Gi
      Copy to Clipboard Toggle word wrap
    • /etc/fstab 파일에 스왑 파티션이 있는지 확인합니다.

      $ grep swap /etc/fstab
      Copy to Clipboard Toggle word wrap

      출력에는 스왑 파티션의 항목이 포함되어야 합니다. 예를 들면 다음과 같습니다.

      /dev/ephemeral0.2   none     swap  sw,nofail,x-systemd.requires=cloud-init.service   0       0
      Copy to Clipboard Toggle word wrap

3.7. Azure 배포를 위한 가상 머신 준비

VM의 호환성이 있고 Azure 환경에서 작동할 수 있도록 사용자 지정 기본 이미지를 배포하기 전에 구성 변경 사항을 수행합니다.

사전 요구 사항

프로세스

  1. VM에 로그인하여 RHEL(Red Hat Enterprise Linux) 리포지토리를 활성화하려면 등록합니다.

    # subscription-manager register
    
    Installed Product Current Status:
    Product Name: Red Hat Enterprise Linux for x86_64
    Status: Subscribed
    Copy to Clipboard Toggle word wrap
  2. cloud-inithyperv-daemons 패키지를 설치합니다.

    # dnf install cloud-init hyperv-daemons -y
    Copy to Clipboard Toggle word wrap
  3. cloud-init 구성 파일을 생성하고 이를 편집하여 Azure 서비스와의 통합을 제공합니다.

    1. KVP(Hyper-V Data Exchange Service)에 로깅을 활성화하려면 /etc/cloud/cloud.cfg.d/10-azure-kvp.cfg 파일을 편집하고 다음 행을 추가합니다.

      reporting:
          logging:
              type: log
          telemetry:
              type: hyperv
      Copy to Clipboard Toggle word wrap
    2. Azure 데이터 소스를 추가하려면 /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg 파일을 편집하고 다음 행을 추가합니다.

      datasource_list: [ Azure ]
      datasource:
          Azure:
              apply_network_config: False
      Copy to Clipboard Toggle word wrap
    3. 임시 디스크에서 스왑 공간을 구성하려면 /etc/cloud/cloud.cfg.d/00-azure-swap.cfg 구성 파일을 만들고 해당 파일에 다음 행을 추가합니다.

      중요

      임시 디스크는 임시 스토리지입니다. 따라서 스왑 공간을 포함하여 저장된 데이터는 VM의 할당 해제 또는 이동 시 손실됩니다. 임시 디스크를 스왑 공간과 같은 임시 데이터에만 사용합니다.

      #cloud-config
      disk_setup:
        ephemeral0:
          table_type: gpt
          layout: [66, [33,82]]
          overwrite: true
      fs_setup:
        - device: ephemeral0.1
          filesystem: ext4
        - device: ephemeral0.2
          filesystem: swap
      mounts:
        - ["ephemeral0.1", "/mnt"]
        - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service", "0", "0"]
      Copy to Clipboard Toggle word wrap
  4. 특정 커널 모듈의 자동 로드를 차단하려면 /etc/modprobe.d/blocklist.conf 파일을 편집하고 다음 행을 추가합니다.

    blacklist nouveau
    blacklist lbm-nouveau
    blacklist floppy
    blacklist amdgpu
    blacklist skx_edac
    blacklist intel_cstate
    Copy to Clipboard Toggle word wrap
  5. udev 네트워크 장치 규칙을 수정합니다.

    1. 있는 경우 다음 영구 네트워크 장치 규칙을 제거합니다.

      # rm -f /etc/udev/rules.d/70-persistent-net.rules
      # rm -f /etc/udev/rules.d/75-persistent-net-generator.rules
      # rm -f /etc/udev/rules.d/80-net-name-slot-rules
      Copy to Clipboard Toggle word wrap
    2. Azure에서 가속 네트워킹을 작동하려면 /etc/udev/rules.d/68-azure-sriov-nm-unmanaged.rules 새 네트워크 장치 규칙을 편집하고 다음 행을 추가합니다.

      SUBSYSTEM=="net", DRIVERS=="hv_pci", ACTION=="add", ENV{NM_UNMANAGED}="1"
      Copy to Clipboard Toggle word wrap
  6. 자동으로 시작하도록 sshd 서비스를 설정합니다.

    # systemctl enable sshd
    # systemctl is-enabled sshd
    Copy to Clipboard Toggle word wrap
  7. 커널 부팅 매개변수 수정:

    1. /etc/default/grub 파일에서 GRUB_TIMEOUT 매개변수 값을 업데이트합니다.

      GRUB_TIMEOUT=10
      Copy to Clipboard Toggle word wrap
    2. GRUB_CMDLINE_LINUX 행 끝에 다음 옵션을 제거합니다.

      rhgb quiet
      Copy to Clipboard Toggle word wrap
    3. 다음 구성 세부 정보를 사용하여 /etc/default/grub 파일을 업데이트합니다.

      GRUB_CMDLINE_LINUX="loglevel=3 crashkernel=auto console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300"
      GRUB_TIMEOUT_STYLE=countdown
      GRUB_TERMINAL="serial console"
      GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
      Copy to Clipboard Toggle word wrap
      참고

      GRUB_CMDLINE_LINUX 라인 끝에 lift =none 옵션을 추가하면 I/O 스케줄러가 완전히 비활성화됩니다. 이 옵션은 디스크 성능을 최적화하지 않고 실행 순서에 따라 I/O 요청을 처리합니다. 예를 들면 다음과 같습니다.

      • 하드 디스크 드라이브(HDD): 성능 및 처리량이 감소하므로 워크로드를 실행하는 데 적합하지 않습니다.
      • SSD(Solid State Drive): 고성능과 짧은 대기 시간, 따라서 워크로드를 실행하는 데 적합합니다.
    4. grub.cfg 파일을 다시 생성합니다.

      • BIOS 기반 시스템에서 다음을 수행합니다.

        # grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
        Copy to Clipboard Toggle word wrap
      • UEFI 기반 시스템에서 다음을 수행합니다.

        # grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
        Copy to Clipboard Toggle word wrap
        주의

        grub.cfg 를 다시 빌드하는 경로는 BIOS 및 UEFI 기반 머신 모두에서 동일합니다. 원래 grub.cfg 는 BIOS 경로에만 존재합니다. UEFI 경로에는 grub2-mkconfig 명령을 사용하여 수정하거나 다시 생성할 수 없는 스텁 파일이 있습니다.

        시스템에서 grub.cfg 에 기본값이 아닌 위치를 사용하는 경우 그에 따라 명령을 조정합니다.

  8. Windows Azure Linux Agent(WALinuxAgent)를 구성합니다.

    1. WALinuxAgent 패키지를 설치하고 활성화합니다.

      # dnf install WALinuxAgent -y
      # systemctl enable waagent
      Copy to Clipboard Toggle word wrap
    2. WALinuxAgent에서 스왑 구성을 비활성화하려면(cloud-init를 사용하여 스왑을 관리하는 경우 필수) /etc/waagent.conf 파일에서 다음 행을 편집합니다.

      Provisioning.DeleteRootPassword=y
      ResourceDisk.Format=n
      ResourceDisk.EnableSwap=n
      ResourceDisk.SwapSizeMB=0
      Copy to Clipboard Toggle word wrap
      참고

      WALinuxAgent에서 스왑을 비활성화하면 cloud-init 에서 임시 디스크의 스왑 구성을 관리할 수 있습니다.

  9. Azure 프로비저닝을 위해 VM을 준비합니다.

    1. Red Hat Subscription Manager에서 VM 등록을 취소합니다.

      # subscription-manager unregister
      Copy to Clipboard Toggle word wrap
    2. 기존 프로비저닝 세부 정보를 정리합니다.

      # waagent -force -deprovision
      Copy to Clipboard Toggle word wrap
      참고

      이 명령은 Azure에서 VM 프로비저닝을 자동으로 처리할 때 경고를 생성합니다.

    3. 쉘 기록을 지우고 VM을 종료합니다.

      # export HISTSIZE=0
      # poweroff
      Copy to Clipboard Toggle word wrap

다음 단계

3.8. RHEL 이미지를 Azure 디스크 이미지로 변환

Microsoft Azure는 Azure 디스크 이미지(.vhd) 형식을 지원합니다. 이미지를 변환하려면 이미지 파일이 1MB의 배수인 위치에서 시작하고 RHEL 이미지를 qcow2 에서 고정 VHD 형식으로 변환해야 합니다.

참고

다음 명령은 qemu-img 버전 2.12.0을 사용합니다.

사전 요구 사항

프로세스

  1. 이미지를 qcow2에서 raw 형식으로 변환합니다.

    $ qemu-img convert -f qcow2 -O raw <image_example_name>.qcow2 <image_name>.raw
    Copy to Clipboard Toggle word wrap
  2. align.sh 쉘 스크립트를 편집합니다.

    $ vi align.sh
    
    #!/bin/bash
    MB=$((1024 * 1024))
    size=$(qemu-img info -f raw --output json "$1" | gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
    rounded_size=$((($size/$MB + 1) * $MB))
    if [ $(($size % $MB)) -eq  0 ]
    then
     echo "Your image is already aligned. You do not need to resize."
     exit 1
    fi
    echo "rounded size = $rounded_size"
    export rounded_size
    Copy to Clipboard Toggle word wrap
  3. 스크립트를 실행합니다.

    $ sh align.sh <image_example_name>.raw
    Copy to Clipboard Toggle word wrap
  4. 이미지가 이미 정렬되어 있는 경우 크기를 조정할 필요가 없습니다. 메시지가 표시됩니다.

    1. 파일을 고정 VHD 형식으로 변환합니다.

      $ qemu-img convert -f raw -o subformat=fixed,force_size -O vpc <image_example_name>.raw <image_example_name>.vhd
      Copy to Clipboard Toggle word wrap

      변환되면 VHD 파일을 Azure에 업로드할 준비가 된 것입니다.

  5. 값이 표시되면 원시 이미지가 정렬되지 않음을 의미합니다.

    1. 위에 표시된 대로 반올림된 값을 사용하여 원시 파일의 크기를 조정합니다.

      $ qemu-img resize -f raw <image_example_name>.raw +1G
      Copy to Clipboard Toggle word wrap
    2. raw 이미지 파일을 VHD 형식으로 변환합니다.

      $ qemu-img convert -f raw -o subformat=fixed,force_size -O vpc <image_example_name>.raw <image_example_name>.vhd
      Copy to Clipboard Toggle word wrap

      변환되면 VHD 파일을 Azure에 업로드할 준비가 된 것입니다.

다음 단계

3.9. RHEL 이미지의 Azure 리소스 구성

Azure 리소스는 컴퓨팅, 네트워크, 스토리지와 같은 클라우드 기반 리소스 관리의 기본 서비스입니다. VHD 파일을 백업하고 Azure 이미지를 생성하기 전에 Azure 리소스 구성을 완료해야 합니다.

사전 요구 사항

프로세스

  1. Azure 인증 정보를 사용하여 호스트를 인증하고 로그인합니다.

    $ az login
    Copy to Clipboard Toggle word wrap

    브라우저에서 로그인하려면 CLI에서 브라우저에서 Azure 로그인 페이지를 엽니다. 자세한 내용은 브라우저로 로그인 을 참조하십시오.

  2. Azure 리전에 리소스 그룹을 생성합니다.

    $ az group create --name <resource-group> --location <azure-region>
    Copy to Clipboard Toggle word wrap

    예제:

    [clouduser@localhost]$ az group create --name azrhelclirsgrp --location southcentralus
    {
      "id": "/subscriptions//resourceGroups/azrhelclirsgrp",
      "location": "southcentralus",
      "managedBy": null,
      "name": "azrhelclirsgrp",
      "properties": {
        "provisioningState": "Succeeded"
      },
      "tags": null
    }
    Copy to Clipboard Toggle word wrap
  3. 유효한 주식 유지 단위(SKU) 유형을 사용하여 스토리지 계정을 생성합니다. 자세한 내용은 SKU 유형을 참조하십시오.

    $ az storage account create -l <azure-region> -n <storage-account-name> -g <resource-group> --sku <sku_type>
    Copy to Clipboard Toggle word wrap

    예제:

    $ az storage account create -l southcentralus -n azrhelclistact -g azrhelclirsgrp --sku Standard_LRS
    {
      "accessTier": null,
      "creationTime": "2017-04-05T19:10:29.855470+00:00",
      "customDomain": null,
      "encryption": null,
      "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Storage/storageAccounts/azrhelclistact",
      "kind": "StorageV2",
      "lastGeoFailoverTime": null,
      "location": "southcentralus",
      "name": "azrhelclistact",
      "primaryEndpoints": {
        "blob": "https://azrhelclistact.blob.core.windows.net/",
        "file": "https://azrhelclistact.file.core.windows.net/",
        "queue": "https://azrhelclistact.queue.core.windows.net/",
        "table": "https://azrhelclistact.table.core.windows.net/"
    },
    "primaryLocation": "southcentralus",
    "provisioningState": "Succeeded",
    "resourceGroup": "azrhelclirsgrp",
    "secondaryEndpoints": null,
    "secondaryLocation": null,
    "sku": {
      "name": "Standard_LRS",
      "tier": "Standard"
    },
    "statusOfPrimary": "available",
    "statusOfSecondary": null,
    "tags": {},
      "type": "Microsoft.Storage/storageAccounts"
    }
    Copy to Clipboard Toggle word wrap
  4. 스토리지 계정 세부 정보를 표시합니다.

    $ az storage account show-connection-string -n <storage_account_name> -g <resource_group>
    Copy to Clipboard Toggle word wrap

    예제:

    $ az storage account show-connection-string -n azrhelclistact -g azrhelclirsgrp
    {
      "connectionString": "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=azrhelclistact;AccountKey=NreGk...=="
    }
    Copy to Clipboard Toggle word wrap
  5. 시스템을 스토리지 계정에 연결하기 위해 기존 연결 문자열을 내보내 환경 변수를 설정합니다.

    $ export AZURE_STORAGE_CONNECTION_STRING="<storage_connection_string>"
    Copy to Clipboard Toggle word wrap

    예제:

    $ export AZURE_STORAGE_CONNECTION_STRING="DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=azrhelclistact;AccountKey=NreGk...=="
    Copy to Clipboard Toggle word wrap
  6. 스토리지 컨테이너를 생성합니다.

    $ az storage container create -n <container_name>
    Copy to Clipboard Toggle word wrap

    예제:

    $ az storage container create -n azrhelclistcont
    {
      "created": true
    }
    Copy to Clipboard Toggle word wrap
  7. 가상 네트워크를 생성합니다.

    $ az network vnet create -g <resource group> --name <vnet_name> --subnet-name <subnet_name>
    Copy to Clipboard Toggle word wrap

    예제:

    $ az network vnet create --resource-group azrhelclirsgrp --name azrhelclivnet1 --subnet-name azrhelclisubnet1
    {
      "newVNet": {
        "addressSpace": {
          "addressPrefixes": [
          "10.0.0.0/16"
          ]
      },
      "dhcpOptions": {
        "dnsServers": []
      },
      "etag": "W/\"\"",
      "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Network/virtualNetworks/azrhelclivnet1",
      "location": "southcentralus",
      "name": "azrhelclivnet1",
      "provisioningState": "Succeeded",
      "resourceGroup": "azrhelclirsgrp",
      "resourceGuid": "0f25efee-e2a6-4abe-a4e9-817061ee1e79",
      "subnets": [
        {
          "addressPrefix": "10.0.0.0/24",
          "etag": "W/\"\"",
          "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Network/virtualNetworks/azrhelclivnet1/subnets/azrhelclisubnet1",
          "ipConfigurations": null,
          "name": "azrhelclisubnet1",
          "networkSecurityGroup": null,
          "provisioningState": "Succeeded",
          "resourceGroup": "azrhelclirsgrp",
          "resourceNavigationLinks": null,
          "routeTable": null
        }
      ],
      "tags": {},
      "type": "Microsoft.Network/virtualNetworks",
      "virtualNetworkPeerings": null
      }
    }
    Copy to Clipboard Toggle word wrap

3.10. Azure Blob 스토리지에 VHD 이미지 업로드

Microsoft Azure Blob 스토리지를 사용하면 VHD 파일을 관리하고 사용자 지정 Azure 이미지를 생성할 수 있습니다.

주의

내보낸 스토리지 연결 문자열은 시스템을 재부팅한 후에도 지속되지 않습니다. 다음 단계의 명령이 하나라도 실패하면 연결 문자열을 다시 내보냅니다. 연결 문자열 을 가져오고 내보내려면 RHEL 이미지의 Azure 리소스 구성 을 참조하십시오.

사전 요구 사항

프로세스

  1. VHD 파일을 스토리지 컨테이너에 업로드합니다.

    $ az storage blob upload \
        --account-name _<storage_account_name> --container-name _<container_name> \
        --type page --file _<path_to_vhd> --name _<image_name>.vhd
    Copy to Clipboard Toggle word wrap

    예제:

    $ az storage blob upload \
    --account-name azrhelclistact --container-name azrhelclistcont \
    --type page --file ~/Downloads/rhel-image-10.vhd --name rhel-image-10.vhd
    
    Percent complete: 100.0%
    Copy to Clipboard Toggle word wrap
  2. 스토리지 컨테이너를 나열합니다.

    1. 표 형식으로 표시하려면 다음을 입력합니다.

      $ az storage container list --output table
      Copy to Clipboard Toggle word wrap
    2. YAML 형식으로 표시하려면 다음을 입력합니다.

      $ az storage container list --output yaml
      Copy to Clipboard Toggle word wrap
  3. 첫 번째 단계에서 업로드된 VHD 파일의 URL을 사용합니다.

    $ az storage blob url -c <container_name> -n _<image_name>.vhd _<url_of_vhd_file>_
    Copy to Clipboard Toggle word wrap

    예제:

    $ az storage blob url -c azrhelclistcont -n rhel-image-10.vhd "https://azrhelclistact.blob.core.windows.net/azrhelclistcont/rhel-image-10.vhd"
    Copy to Clipboard Toggle word wrap
  4. Azure 사용자 지정 이미지를 생성합니다.

    $ az image create -n _<image_name> -g _<resource_group> -l _<azure_region> --source _<URL> --os-type linux
    Copy to Clipboard Toggle word wrap
    참고

    VM의 기본 하이퍼바이저 생성은 V1입니다. 선택 옵션으로 --hyper-v-generation V2 옵션을 포함하여 V2 하이퍼바이저 생성을 지정할 수 있습니다. 생성 2 VM은 UEFI 기반 부팅 아키텍처를 사용합니다. 자세한 내용은 Azure에서 2세대 VM 지원을 참조하십시오. 명령은 "VHD로 포맷된 Blob만 가져올 수 있습니다."라는 오류를 반환할 수 있습니다. 이 오류는 VHD로 변환되기 전에 이미지가 가장 가까운 1MB 경계에 정렬되지 않았음을 의미할 수 있습니다.

    예제:

    $ az image create -n rhel10 -g azrhelclirsgrp2 -l southcentralus --source https://azrhelclistact.blob.core.windows.net/azrhelclistcont/rhel-image-10.vhd --os-type linux
    Copy to Clipboard Toggle word wrap

다음 단계

3.11. Azure에서 RHEL VM 시작 및 연결

이미지에서 관리 디스크 Azure VM을 생성해야 합니다.

사전 요구 사항

프로세스

  1. VM을 생성합니다.

    $ az vm create \
        -g <resource_group> -l <azure_region> -n <vm_name> \
        --vnet-name <vnet_name> --subnet <subnet_name> --size Standard_A2 \
        --os-disk-name <simple_name> --admin-username <administrator_name> \
        --generate-ssh-keys --image <path_to_image>
    Copy to Clipboard Toggle word wrap

    예제:

    $ az vm create \
    -g azrhelclirsgrp2 -l southcentralus -n rhel-azure-vm-1 \ 
    1
    
    --vnet-name azrhelclivnet1 --subnet azrhelclisubnet1 --size Standard_A2 \
    --os-disk-name vm-1-osdisk --admin-username clouduser \ 
    2
    
    --generate-ssh-keys --image rhel10
    
    {
      "fqdns": "",
      "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Compute/virtualMachines/rhel-azure-vm-1",
      "location": "southcentralus",
      "macAddress": "",
      "powerState": "VM running",
      "privateIpAddress": "10.0.0.4",
      "publicIpAddress": "<public_ip_address>",
      "resourceGroup": "azrhelclirsgrp2"
    }
    Copy to Clipboard Toggle word wrap
    • --generate-ssh-keys 옵션은 ~/.ssh 디렉터리에 개인 키 쌍 파일을 생성합니다.
    • 공개 키는 --admin-username 옵션으로 지정한 사용자에 대해 VM의 authorized_keys 파일에 추가됩니다.

      자세한 내용은 SSH 인증 방법 유형을 참조하십시오. 다음 단계에서 VM에 로그인해야 하는 publicIpAddress 에 유의하십시오.

  2. SSH 세션을 시작하고 Azure VM에 로그인합니다.

    [clouduser@localhost]$ ssh -i /home/clouduser/.ssh/id_rsa clouduser@<public_ip_address>
    
    The authenticity of host '<public_ip_address>' can't be established.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '<public_ip_address>' (ECDSA) to the list of known hosts.
    Copy to Clipboard Toggle word wrap

검증

  • VM에 성공적으로 연결하면 사용자 프롬프트가 표시됩니다.
  • Microsoft Azure 포털을 사용하여 감사 로그를 확인하고 할당된 리소스 속성을 확인하고 가상 머신을 관리합니다. 자세한 내용은 자습서: Azure 포털을 사용하여 Linux VM 만들기 및 관리를 참조하십시오.
  • 여러 VM을 관리하는 경우 Azure CLI를 사용할 수도 있습니다. 자세한 내용은 CLI에 az --help 를 입력하거나 Azure CLI 명령 참조를 참조하십시오.

3.12. SSH 인증 방법 유형

중요한 보안 관행이지만 경우에 따라 Azure 생성 키 쌍 없이 Azure 인스턴스에 연결할 수도 있습니다. 다음 예제에서는 SSH 인증을 위한 두 가지 방법을 보여줍니다.

예시 1
공개 키 파일을 생성하지 않고 암호로 새 Azure VM을 프로비저닝합니다.
$ az vm create \
    -g <resource_group> -l <azure_region> -n <vm_name> \
    -vnet-name <vnet_name> -subnet <subnet_name> -size Standard_A2 \
    -os-disk-name <simple_name> -authentication-type password \
    -admin-username <administrator_name> -admin-password <ssh_password> -image <path_to_image>
Copy to Clipboard Toggle word wrap
$ ssh <admin_username>@<public_ip_address>
Copy to Clipboard Toggle word wrap
예시 2
기존 공개 키 파일을 사용하여 새 Azure VM을 프로비저닝합니다.
$ az vm create \
    -g <resource_group> -l <azure_region> -n <vm_name> \
    -vnet-name <vnet_name> -subnet <subnet_name> -size Standard_A2 \
    -os-disk-name <simple_name> -admin-username <administrator_name> \
    -ssh-key-value <path_to_existing_ssh_key> -image <path_to_image>
Copy to Clipboard Toggle word wrap
$ ssh -i <path_to_existing_ssh_key> <admin_username>@<public_ip_address>
Copy to Clipboard Toggle word wrap

3.13. Red Hat 서브스크립션 첨부

subscription-manager 명령을 사용하여 Red Hat 서브스크립션을 RHEL 인스턴스에 등록하고 연결할 수 있습니다.

사전 요구 사항

프로세스

  1. 시스템을 등록합니다.

    # subscription-manager register
    Copy to Clipboard Toggle word wrap
  2. 서브스크립션을 연결합니다.

  3. 선택 사항: Red Hat Hybrid Cloud Console 의 인스턴스에 대한 다양한 시스템 지표를 수집하려면 Red Hat Lightspeed 에 인스턴스를 등록할 수 있습니다.

    # insights-client register --display-name <display_name_value>
    Copy to Clipboard Toggle word wrap

    Red Hat Lightspeed의 추가 구성에 대한 자세한 내용은 Red Hat Lightspeed 용 클라이언트 구성 가이드를 참조하십시오.

3.14. Azure Gold 이미지에 자동 등록 설정

Microsoft Azure에 RHEL VM(가상 머신)을 더 빠르고 쉽게 배포하기 위해 RHEL의 골드 이미지를 RHSM(Red Hat Subscription Management)에 자동으로 등록할 수 있습니다.

사전 요구 사항

  • RHEL gold 이미지는 Microsoft Azure에서 사용할 수 있습니다. 자세한 내용은 Azure에서 골드 이미지 사용을 참조하십시오.

    참고

    Microsoft Azure 계정은 한 번에 하나의 Red Hat 계정에만 연결할 수 있습니다. 따라서 다른 사용자가 Red Hat 계정에 연결하기 전에 Azure 계정에 액세스할 필요가 없는지 확인합니다.

프로세스

  • gold 이미지를 사용하여 Azure 인스턴스에 RHEL VM을 생성합니다. 자세한 내용은 Azure에서 RHEL VM 시작 및 연결을 참조하십시오.

    RHSM 설정이 올바르면 VM이 RHSM에 자동으로 서브스크립션됩니다.

검증

  • 위의 지침을 사용하여 생성된 RHEL VM에서 RHSM이 시스템에 연결되어 있는지 확인합니다. 성공적으로 등록된 시스템에서 subscription-manager identity 명령은 시스템의 UUID를 표시합니다. 예를 들면 다음과 같습니다.

    # subscription-manager identity
    system identity: fdc46662-c536-43fb-a18a-bbcb283102b7
    name: 192.168.122.222
    org name: 6340056
    org ID: 6340056
    Copy to Clipboard Toggle word wrap

3.15. Microsoft Azure 인스턴스의 kdump 구성

RHEL 인스턴스에서 커널 충돌이 발생하면 kdump 서비스를 사용하여 원인을 확인할 수 있습니다. 커널 인스턴스가 예기치 않게 종료되면 kdump 에서 크래시 덤프 또는 vmcore 파일이라는 덤프 파일을 생성합니다. 디버깅의 경우 파일을 분석하여 크래시가 발생한 이유를 확인할 수 있습니다.

kdump 가 Microsoft Azure 인스턴스에서 작동하려면 kdump 예약된 메모리와 vmcore 대상을 VM 크기와 RHEL 버전에 맞게 조정해야 할 수 있습니다.

사전 요구 사항

  • kdump 를 지원하는 Microsoft Azure 환경의 VM을 사용하고 있습니다.

    • Standard_DS2_v2
    • 표준 NV16as v4
    • 표준 M416-208s v2
    • 표준 M416ms v2
  • root 권한이 있습니다.
  • 시스템은 kdump 구성 및 대상에 대한 요구 사항을 충족합니다. 자세한 내용은 지원되는 kdump 구성 및 대상 을 참조하십시오.

프로세스

  1. kdump 및 기타 필수 패키지를 설치합니다.

    # dnf install kexec-tools kdump-utils makedumpfile
    Copy to Clipboard Toggle word wrap
  2. 크래시 덤프 파일의 기본 위치가 kdump 구성 파일에 설정되어 있고 /var/crash 파일을 사용할 수 있는지 확인합니다.

    # grep -v "#" /etc/kdump.conf
    
    path /var/crash
    core_collector makedumpfile -l --message-level 7 -d 31
    Copy to Clipboard Toggle word wrap
  3. RHEL VM 크기 및 버전을 기반으로 /mnt/crash 와 같이 더 많은 여유 공간이 있는 vmcore 대상이 필요한지 확인합니다.

    Expand
    표 3.3. Azure에서 GEN2 VM 에서 테스트된 가상 머신 크기
    RHEL 버전표준 DS1 v2 (1 vCPU, 3.5GiB)표준 NV16as v4 (16 vCPU, 56GiB)표준 M416-208s v2 (208 vCPUs, 5700GiB)표준 M416ms v2 (416 vCPUs, 11400GiB)

    RHEL 9.4 - RHEL 10

    기본

    기본

    대상

    대상

    • defaultkdump 가 기본 메모리 및 기본 kdump 대상에서 예상대로 작동함을 나타냅니다. 기본 kdump 대상은 /var/crash 파일입니다.
    • targetkdump 가 기본 메모리에서 예상대로 작동함을 나타냅니다. 그러나 더 많은 여유 공간이 있는 대상을 할당해야 할 수 있습니다.
  4. /mnt/crash 와 같은 여유 공간이 있는 대상을 할당하려면 /etc/kdump.conf 파일을 편집하고 기본 경로를 바꿉니다.

    $ sed s/"path /var/crash"/"path /mnt/crash"
    Copy to Clipboard Toggle word wrap

    옵션 경로 /mnt/crashkdump 에서 크래시 덤프 파일을 저장하는 파일 시스템의 경로를 나타냅니다.

    크래시 덤프 파일을 다른 파티션에 직접 작성하거나 원격 머신에 저장하는 것과 같은 자세한 내용은 kdump 대상 구성을 참조하십시오.

  5. 인스턴스가 필요한 경우 상대 부팅 매개변수를 추가하여 크래시 커널 크기를 kdump 에 충분한 크기로 늘리십시오.

    예를 들어 Standard M416-208s v2 VM의 경우 충분한 크기는 512MB이므로 부팅 매개 변수는 crashkernel=512M 입니다.

    1. GRUB 설정 파일을 열고 crashkernel=512M 을 부팅 매개변수 행에 추가합니다.

      # vi /etc/default/grub
      
      GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 crashkernel=512M"
      Copy to Clipboard Toggle word wrap
    2. GRUB 설정 파일을 업데이트합니다.

      # grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
      Copy to Clipboard Toggle word wrap
  6. VM을 재부팅하여 별도의 커널 크래시 메모리를 VM에 할당합니다.

검증

  • kdump 가 활성화되어 있고 실행 중인지 확인합니다.

    # systemctl status kdump
    ● kdump.service - Crash recovery kernel arming
       Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor prese>
       Active: active (exited) since Fri 2024-02-09 10:50:18 CET; 1h 20min ago
      Process: 1252 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCES>
     Main PID: 1252 (code=exited, status=0/SUCCESS)
        Tasks: 0 (limit: 16975)
       Memory: 512B
       CGroup: /system.slice/kdump.service
    Copy to Clipboard Toggle word wrap

4장. Microsoft Azure에서 Red Hat High Availability 클러스터 구성

HA(고가용성) 클러스터는 RHEL 노드를 그룹화하여 노드가 실패하면 워크로드가 자동으로 재배포되도록 합니다. Microsoft Azure를 포함한 퍼블릭 클라우드 플랫폼에 HA 클러스터를 배포할 수 있습니다. Azure에서 HA 클러스터를 설정하는 프로세스는 기존의 클라우드 이외의 환경에서 이를 구성하는 데 적합합니다.

VHD(가상 하드 드라이브) 인스턴스를 클러스터 노드로 사용하는 Azure에서 Red Hat HA 클러스터를 구성하려면 다음 섹션을 참조하십시오. 클러스터의 RHEL 이미지를 가져오는 몇 가지 옵션이 있습니다. 자세한 내용은 퍼블릭 클라우드에 사용 가능한 RHEL 이미지 유형을 참조하십시오.

시작하기 전에 다음 단계를 완료해야 합니다.

HA(고가용성) 클러스터는 특정 워크로드를 실행하기 위해 일련의 컴퓨터( 노드라고 함)를 연결합니다. HA 클러스터는 하드웨어 또는 소프트웨어 오류를 처리하기 위해 중복성을 제공합니다. HA 클러스터의 노드가 실패하면 Pacemaker 클러스터 리소스 관리자가 워크로드를 다른 노드에 빠르게 분배하여 눈에 띄는 다운타임 없이 클러스터의 서비스를 계속할 수 있습니다.

퍼블릭 클라우드 플랫폼에서 HA 클러스터를 실행할 수도 있습니다. 이 경우 클라우드에서 VM(가상 머신) 인스턴스를 개별 클러스터 노드로 사용합니다. 퍼블릭 클라우드 플랫폼에서 HA 클러스터를 사용하면 다음과 같은 이점이 있습니다.

  • 가용성 개선: VM 장애의 경우 워크로드가 다른 노드에 빠르게 재배포되므로 실행 중인 서비스가 중단되지 않습니다.
  • 확장성: 수요가 높을 때 추가 노드를 시작하고 수요가 낮으면 중지할 수 있습니다.
  • 비용 효율성: pay-as-you-go 가격을 사용하면 실행 중인 노드에 대해서만 비용을 지불합니다.
  • 간소화된 관리: 일부 퍼블릭 클라우드 플랫폼은 HA 클러스터를 보다 쉽게 구성할 수 있도록 관리 인터페이스를 제공합니다.

RHEL 시스템에서 HA를 활성화하기 위해 Red Hat은 HA 애드온을 제공합니다. RHEL 서버 그룹으로 HA 클러스터를 관리하도록 Red Hat HA 애드온을 사용하여 RHEL 클러스터를 구성할 수 있습니다. Red Hat HA 애드온은 통합 및 간소화된 툴에 액세스할 수 있도록 지원합니다. 클러스터 리소스 관리자, 펜싱 에이전트 및 리소스 에이전트를 사용하면 자동화를 위해 클러스터를 설정하고 구성할 수 있습니다. Red Hat HA 애드온은 자동화를 위한 다음과 같은 구성 요소를 제공합니다.

  • Pacemaker: 여러 노드를 지원하는 명령줄 유틸리티(pcs)와 GUI(pcsd)를 모두 제공하는 클러스터 리소스 관리자
  • HA 클러스터를 생성하고 관리하는 CorosyncKronosnet
  • 사용자 지정 애플리케이션을 구성하고 관리하는 리소스 에이전트
  • 베어 메탈 서버 및 가상 머신과 같은 플랫폼에서 클러스터를 사용하는 펜싱 에이전트

Red Hat HA 애드온은 내결함성 및 시스템 안정성에 대한 노드 장애, 로드 밸런싱 및 노드 상태 점검과 같은 중요한 작업을 처리합니다.

4.2. Azure용 고가용성 패키지 및 에이전트 설치

각 노드에서 Azure에서 Red Hat High Availability 클러스터를 구성하려면 고가용성 패키지 및 에이전트를 설치해야 합니다.

주요 목표는 내결함성 고가용성 시스템을 생성하는 것을 목표로 하지만 이러한 특정 패키지를 설치하면 다음과 같은 기능을 수행할 수 있습니다.

  • 자동 장애 조치 기능 - 하나의 노드가 실패하면 서비스가 정상 노드로 자동으로 이동합니다.
  • 리소스 관리 - 클러스터는 서비스, 데이터베이스, 애플리케이션을 관리하고 모니터링할 수 있습니다.
  • 서비스 연속성 - 하드웨어 또는 소프트웨어 오류 중에도 서비스를 계속 사용할 수 있도록 하여 다운타임 최소화
  • Azure별 통합 - fence-agents-azure-arm 패키지는 Azure별 펜싱 기능을 제공하므로 Azure 환경에서 VM을 중지하거나 네트워크 액세스를 관리하여 오류가 발생한 노드를 안전하게 격리할 수 있습니다.

사전 요구 사항

프로세스

  1. Azure VM의 공용 IP 주소를 가져오려면 Azure 포털에서 VM 속성을 열거나 다음을 입력합니다.

    $ az vm list -g <resource_group> -d --output table
    Copy to Clipboard Toggle word wrap

    예제:

    $ az vm list -g azrhelclirsgrp -d --output table
    
    Name    ResourceGroup           PowerState      PublicIps        Location
    ------  ----------------------  --------------  -------------    --------------
    node01  azrhelclirsgrp          VM running      192.98.152.251    southcentralus
    Copy to Clipboard Toggle word wrap
  2. Red Hat에 VM을 등록합니다.

    $ sudo -i
    # subscription-manager register
    Copy to Clipboard Toggle word wrap
  3. 모든 저장소 비활성화:

    # subscription-manager repos --disable= *
    Copy to Clipboard Toggle word wrap
  4. RHEL Server HA 리포지토리를 활성화합니다.

    # subscription-manager repos --enable=rhel-10-for-x86_64-highavailability-rpms
    Copy to Clipboard Toggle word wrap
  5. 모든 패키지 업데이트:

    # dnf update -y
    Copy to Clipboard Toggle word wrap
  6. Azure 펜싱 에이전트와 함께 Red Hat HA 애드온 패키지를 설치합니다.

    # dnf install pcs pacemaker fence-agents-azure-arm
    Copy to Clipboard Toggle word wrap
  7. pcspacemaker 설치로 마지막 단계에서 hacluster 사용자가 생성되었습니다. 이제 hacluster 의 암호를 생성하여 모든 클러스터 노드에 사용합니다.

    # passwd hacluster
    Copy to Clipboard Toggle word wrap
  8. 시스템에 firewalld.service 가 있는 경우 RHEL 방화벽에 고가용성 서비스를 추가합니다.

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
  9. pcs 서비스를 시작하고 부팅 시 시작되도록 활성화합니다.

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
    
    Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
    Copy to Clipboard Toggle word wrap

검증

  • pcs 서비스가 실행 중인지 확인합니다.

    # systemctl status pcsd.service
    ...
    Active: active (running) since Fri 2018-02-23 11:00:58 EST; 1min 23s ago
    ...
    Copy to Clipboard Toggle word wrap

4.3. Azure AD 애플리케이션 생성

Azure AD(Active Directory) 애플리케이션을 생성하려면 다음 절차를 완료합니다. Azure AD 애플리케이션은 클러스터의 모든 노드에 대한 HA(고가용성) 작업에 대한 액세스를 인증하고 자동화합니다.

사전 요구 사항

  • Azure CLI(명령줄 인터페이스) 가 시스템에 설치되어 있습니다.
  • Azure AD 애플리케이션을 생성하기 위한 Microsoft Azure 서브스크립션의 관리자 또는 소유자입니다.

프로세스

  1. HA 클러스터의 모든 노드에서 Azure 계정에 로그인합니다.

    $ az login
    Copy to Clipboard Toggle word wrap
  2. Azure 차단 에이전트의 사용자 지정 역할에 대한 json 구성 파일을 생성합니다. 다음 구성을 사용하지만 < subscription_id> 를 서브스크립션 ID로 바꿉니다.

    {
          "Name": "Linux Fence Agent Role",
          "description": "Allows to power-off and start virtual machines",
          "assignableScopes": [
                  "/subscriptions/<subscription_id>"
          ],
          "actions": [
                  "Microsoft.Compute/*/read",
                  "Microsoft.Compute/virtualMachines/powerOff/action",
                  "Microsoft.Compute/virtualMachines/start/action"
          ],
          "notActions": [],
          "dataActions": [],
          "notDataActions": []
    }
    Copy to Clipboard Toggle word wrap
  3. Azure 차단 에이전트의 사용자 지정 역할을 정의합니다. 이전 단계에서 생성된 json 파일을 사용합니다.

    $ az role definition create --role-definition <azure_fence_role.json>
    
    {
      "assignableScopes": [
        "/subscriptions/<my_subscription_id>"
      ],
      "description": "Allows to power-off and start virtual machines",
      "id": "/subscriptions/<my_subscription_id>/providers/Microsoft.Authorization/roleDefinitions/<role_id>",
      "name": "<role_id>",
      "permissions": [
        {
          "actions": [
            "Microsoft.Compute/*/read",
            "Microsoft.Compute/virtualMachines/powerOff/action",
            "Microsoft.Compute/virtualMachines/start/action"
          ],
          "dataActions": [],
          "notActions": [],
          "notDataActions": []
        }
      ],
      "roleName": "Linux Fence Agent Role",
      "roleType": "CustomRole",
      "type": "Microsoft.Authorization/roleDefinitions"
    }
    Copy to Clipboard Toggle word wrap
  4. Azure 웹 콘솔 인터페이스의 가상 머신 → 왼쪽 메뉴에서 ID 를 클릭합니다.
  5. On → click Save → click Yes to confirm를 선택합니다.
  6. Azure 역할 할당역할 할당 추가를 클릭합니다.
  7. 역할에 필요한 범위 (예 : 리소스 그룹 )를 선택합니다.
  8. 필요한 리소스 그룹을 선택합니다.
  9. 선택 사항: 필요한 경우 서브스크립션 을 변경합니다.
  10. Linux Fence Agent Role 역할을 선택합니다.
  11. 저장을 클릭합니다.

검증

  • Azure AD에서 표시되는 노드를 표시합니다.

    # fence_azure_arm --msi -o list
    node1,
    node2,
    [...]
    Copy to Clipboard Toggle word wrap

    이 명령이 클러스터의 모든 노드를 출력하는 경우 AD 애플리케이션을 성공적으로 구성했습니다.

4.4. 고가용성 클러스터 생성

다음 절차에 따라 Red Hat High Availability Add-On 클러스터를 생성합니다. 이 예제 절차에서는 z1.example.comz2.example.com 노드로 구성된 클러스터를 생성합니다.

참고

pcs 명령의 매개변수와 해당 매개변수에 대한 설명을 표시하려면 pcs 명령의 -h 옵션을 사용합니다.

프로세스

  1. pcs 를 실행할 노드의 클러스터의 각 노드에 대해 pcs user hacluster 를 인증합니다.

    다음 명령은 z1.example.comz2.example.com 으로 구성된 2-노드 클러스터의 두 노드에 대해 z1.example.com 의 사용자 hacluster 를 인증합니다.

    [root@z1 ~]# pcs host auth z1.example.com z2.example.com
    Username: hacluster
    Password:
    z1.example.com: Authorized
    z2.example.com: Authorized
    Copy to Clipboard Toggle word wrap
  2. z1.example.com 에서 다음 명령을 실행하여 z1.example.com 및 z2.example.com 노드로 구성된 2-노드 클러스터 my_cluster 를 생성합니다. 이렇게 하면 클러스터 구성 파일이 클러스터의 두 노드에 모두 전파됩니다. 이 명령에는 클러스터의 두 노드에서 클러스터 서비스를 시작하는 --start 옵션이 포함되어 있습니다.

    [root@z1 ~]# pcs cluster setup my_cluster --start z1.example.com z2.example.com
    Copy to Clipboard Toggle word wrap
  3. 노드가 부팅될 때 클러스터의 각 노드에서 클러스터 서비스를 실행하도록 활성화합니다.

    참고

    특정 환경의 경우 이 단계를 건너뛰어 클러스터 서비스를 비활성화 상태로 두도록 선택할 수 있습니다. 이를 통해 노드가 중단되면 노드가 클러스터에 다시 참여하기 전에 클러스터 또는 리소스의 문제가 해결되도록 할 수 있습니다. 클러스터 서비스를 비활성화한 상태로 두면 해당 노드에서 pcs cluster start 명령을 실행하여 노드를 재부팅할 때 서비스를 수동으로 시작해야 합니다.

    [root@z1 ~]# pcs cluster enable --all
    Copy to Clipboard Toggle word wrap
  4. pcs cluster status 명령을 사용하여 생성한 클러스터의 상태를 표시합니다. pcs cluster setup 명령의 --start 옵션을 사용하여 클러스터 서비스를 시작하고 실행하기 전에 클러스터가 잠시 지연될 수 있으므로 클러스터와 해당 구성에서 후속 작업을 수행하기 전에 클러스터가 가동 및 실행 중인지 확인해야 합니다.

    [root@z1 ~]# pcs cluster status
    Cluster Status:
     Stack: corosync
     Current DC: z2.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
     Last updated: Thu Oct 11 16:11:18 2018
     Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z2.example.com
     2 Nodes configured
     0 Resources configured
    
    ...
    Copy to Clipboard Toggle word wrap

4.5. Red Hat High Availability 클러스터에서 펜싱 구성

클러스터의 단일 노드와 통신하는 데 실패하는 경우 클러스터의 다른 노드는 실패한 클러스터 노드에서 액세스할 수 있는 리소스에 대한 액세스를 제한하거나 해제할 수 있어야 합니다. 클러스터 노드가 응답하지 않을 수 있으므로 클러스터 노드에 직접 연결하여 이 작업을 수행할 수 없습니다. 대신 차단 에이전트를 사용한 펜싱이라는 외부 방법을 제공해야 합니다. 차단 장치는 클러스터가 잘못된 노드에 의해 공유 리소스에 대한 액세스를 제한하거나 클러스터 노드에서 하드 재부팅을 발행하는 데 사용할 수 있는 외부 장치입니다.

차단 장치를 구성하지 않으면 연결이 끊긴 클러스터 노드에서 이전에 사용한 리소스가 해제되었음을 알 수 없으며 이로 인해 서비스가 다른 클러스터 노드에서 실행되지 않을 수 있습니다. 반대로 시스템은 클러스터 노드가 리소스를 해제한 것으로 잘못 가정할 수 있으며 이로 인해 데이터가 손상되고 데이터가 손실될 수 있습니다. 차단 장치가 구성된 데이터 무결성을 보장할 수 없으며 클러스터 구성은 지원되지 않습니다.

펜싱이 진행 중인 경우 다른 클러스터 작업을 실행할 수 없습니다. 클러스터의 정상적인 작업은 펜싱이 완료되거나 클러스터 노드가 재부팅된 후 클러스터에 다시 참여할 때까지 다시 시작할 수 없습니다. Red Hat High Availability 클러스터의 펜싱 및 중요성에 대한 자세한 내용은 Red Hat High Availability Cluster의 Red Hat 지식베이스 솔루션 Fencing 을 참조하십시오.

4.5.1. 사용 가능한 차단 에이전트 및 옵션 표시

다음 명령은 특정 펜싱 에이전트에서 사용 가능한 펜싱 에이전트 및 사용 가능한 옵션을 확인하는 데 사용할 수 있습니다.

참고

시스템의 하드웨어에 따라 클러스터에 사용할 펜싱 장치 유형이 결정됩니다. 지원되는 플랫폼 및 아키텍처 및 다양한 펜싱 장치에 대한 자세한 내용은 RHEL 고가용성 클러스터에 대한 지원 정책의 Red Hat 지식 베이스 문서 Cluster Platform 및 아키텍처 섹션을 참조하십시오.

다음 명령을 실행하여 사용 가능한 모든 펜싱 에이전트를 나열합니다. 필터를 지정하면 이 명령은 필터와 일치하는 펜싱 에이전트만 표시합니다.

pcs stonith list [filter]
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 지정된 펜싱 에이전트의 옵션을 표시합니다.

pcs stonith describe [stonith_agent]
Copy to Clipboard Toggle word wrap

예를 들어 다음 명령은 telnet/SSH를 통한 APC에 대한 차단 에이전트의 옵션을 표시합니다.

# pcs stonith describe fence_apc
Stonith options for: fence_apc
  ipaddr (required): IP Address or Hostname
  login (required): Login Name
  passwd: Login password or passphrase
  passwd_script: Script to retrieve password
  cmd_prompt: Force command prompt
  secure: SSH connection
  port (required): Physical plug number or name of virtual machine
  identity_file: Identity file for ssh
  switch: Physical switch number on device
  inet4_only: Forces agent to use IPv4 addresses only
  inet6_only: Forces agent to use IPv6 addresses only
  ipport: TCP port to use for connection with device
  action (required): Fencing Action
  verbose: Verbose mode
  debug: Write debug information to given file
  version: Display version information and exit
  help: Display help and exit
  separator: Separator for CSV created by operation list
  power_timeout: Test X seconds for status change after ON/OFF
  shell_timeout: Wait X seconds for cmd prompt after issuing command
  login_timeout: Wait X seconds for cmd prompt after login
  power_wait: Wait X seconds after issuing ON/OFF
  delay: Wait X seconds before fencing is started
  retry_on: Count of attempts to retry power on
Copy to Clipboard Toggle word wrap
주의

메서드 옵션을 제공하는 차단 에이전트의 경우 fence_sbd 에이전트를 제외하고 주기 값이 지원되지 않으며 데이터 손상이 발생할 수 있으므로 지정하지 않아야 합니다. 그러나 fence_sbd 의 경우에도 메서드를 지정하지 않고 기본값을 사용해야 합니다.

4.5.2. 차단 장치 생성

펜스 장치를 생성하는 명령의 형식은 다음과 같습니다. 사용 가능한 차단 장치 생성 옵션 목록은 pcs stonith -h 디스플레이를 참조하십시오.

pcs stonith create stonith_id stonith_device_type [stonith_device_options] [op  operation_action operation_options]
Copy to Clipboard Toggle word wrap

다음 명령은 단일 노드에 대한 단일 펜싱 장치를 생성합니다.

# pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
Copy to Clipboard Toggle word wrap

일부 차단 장치는 단일 노드만 펜싱할 수 있지만 다른 장치는 여러 노드를 펜싱할 수 있습니다. 차단 장치를 생성할 때 지정하는 매개변수는 차단 장치가 지원하고 요구하는 사항에 따라 다릅니다.

  • 일부 차단 장치는 펜싱할 수 있는 노드를 자동으로 결정할 수 있습니다.
  • 차단 장치를 생성할 때 pcmk_host_list 매개 변수를 사용하여 해당 펜싱 장치에서 제어하는 모든 시스템을 지정할 수 있습니다.
  • 일부 차단 장치에는 호스트 이름을 펜스 장치에서 이해하는 사양에 매핑해야 합니다. 펜싱 장치를 생성할 때 pcmk_host_map 매개변수를 사용하여 호스트 이름을 매핑할 수 있습니다.

pcmk_host_listpcmk_host_map 매개변수에 대한 자세한 내용은 펜싱 장치의 일반 속성을 참조하십시오.

펜스 장치를 구성한 후에는 장치를 테스트하여 올바르게 작동하는지 확인해야 합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.

4.5.3. 펜싱 장치의 일반 속성

펜싱 장치에 대해 설정할 수 있는 일반 속성과 펜싱 동작을 결정하는 다양한 클러스터 속성이 있습니다.

클러스터 노드는 fence 리소스가 시작 또는 중지되었는지 여부에 관계없이 모든 차단 장치로 다른 클러스터 노드를 펜싱할 수 있습니다. 리소스가 시작되었는지 여부는 다음 예외와 함께 사용할 수 있는지 여부에 관계없이 장치에 대한 반복 모니터만 제어합니다.

  • pcs stonith_id명령을 실행하여 펜싱 장치를 비활성화할 수 있습니다. 이렇게 하면 모든 노드가 해당 장치를 사용하지 않습니다.
  • 특정 노드에서 펜싱 장치를 사용하지 않도록 pcs 제약 조건 위치 …​ avoids 명령을 사용하여 펜싱 리소스에 대한 위치 제약 조건 을 구성할 수 있습니다.
  • stonith-enabled=false 를 구성하면 펜싱이 완전히 비활성화됩니다. 그러나 Red Hat은 프로덕션 환경에 적합하지 않으므로 펜싱이 비활성화된 경우 클러스터를 지원하지 않습니다.

다음 표에서는 펜싱 장치에 대해 설정할 수 있는 일반 속성을 설명합니다.

Expand
표 4.1. 펜싱 장치의 일반 속성
필드유형Default설명

pcmk_host_map

string

 

호스트 이름을 지원하지 않는 장치의 포트 번호에 호스트 이름 매핑. 예를 들어 node1:1;node2:2,3 은 node1에 포트 1과 node2에 포트 2 및 3을 사용하도록 클러스터에 지시합니다. pcmk_host_map 속성은 값 앞의 백슬래시를 사용하여 pcmk_host_map 값 내에서 특수 문자를 지원합니다. 예를 들어 호스트 별칭에 공백을 포함하도록 pcmk_host_map="node3:plug\ 1" 을 지정할 수 있습니다.

pcmk_host_list

string

 

이 장치에서 제어하는 머신 목록입니다( pcmk_host_check=static-list가 아닌 경우 선택 사항 ).

pcmk_host_check

string

* pcmk_host_list 또는 pcmk_host_map 이 설정된 경우 static-list

* 그렇지 않으면 차단 장치가 목록 작업을 지원하는 경우 dynamic- list

* 그렇지 않으면 차단 장치가 상태 작업을 지원하는 경우 상태

* 다른 방법 , 없음

장치에서 제어하는 머신을 결정하는 방법 허용되는 값: dynamic-list (장치 쿼리), static-list ( pcmk_host_list 특성 확인), none(모든 장치가 모든 장치를 펜싱할 수 있음)

다음 표에는 펜싱 장치에 설정할 수 있는 추가 속성이 요약되어 있습니다. 이러한 속성은 고급 용도로만 사용됩니다.

Expand
표 4.2. 펜싱 장치의 고급 속성
필드유형Default설명

pcmk_host_argument

string

port

포트 대신 제공할 대체 매개변수입니다. 일부 장치는 표준 포트 매개 변수를 지원하지 않거나 추가 포트를 제공할 수 있습니다. 이를 사용하여 시스템을 펜싱해야 함을 나타내는 대체 장치별 매개 변수를 지정합니다. 값이 none 인 값을 사용하여 클러스터에 추가 매개변수를 제공하지 않도록 지시할 수 있습니다.

pcmk_reboot_action

string

reboot

재부팅 하지 않고 실행할 대체 명령입니다. 일부 장치는 표준 명령을 지원하지 않거나 추가 명령을 제공할 수 있습니다. 이를 사용하여 재부팅 작업을 구현하는 대체 장치별 명령을 지정합니다.

pcmk_reboot_timeout

time

60s

stonith-timeout 대신 재부팅 작업에 사용할 대체 타임아웃을 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 재부팅 작업에 대한 대체 장치별 시간 초과를 지정합니다.

pcmk_reboot_retries

integer

2

시간 제한 기간 내에 재부팅 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker에서 재부팅 작업을 포기하기 전에 재부팅 작업을 재시도하는 횟수를 변경합니다.

pcmk_off_action

string

off

off 대신 실행할 대체 명령입니다. 일부 장치는 표준 명령을 지원하지 않거나 추가 명령을 제공할 수 있습니다. 이 명령을 사용하여 off 작업을 구현하는 대체 장치별 명령을 지정합니다.

pcmk_off_timeout

time

60s

stonith-timeout 대신 off 작업에 사용할 대체 타임아웃을 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 off 작업에 대한 대체 장치별 시간 초과를 지정합니다.

pcmk_off_retries

integer

2

시간 제한 기간 내에 off 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker에서 중단하기 전에 작업을 재시도하는 횟수를 변경합니다.

pcmk_list_action

string

list

목록 대신 실행할 대체 명령입니다. 일부 장치는 표준 명령을 지원하지 않거나 추가 명령을 제공할 수 있습니다. 이를 사용하여 목록 작업을 구현하는 대체 장치별 명령을 지정합니다.

pcmk_list_timeout

time

60s

목록 작업에 사용할 대체 시간 초과를 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 목록 작업에 대한 대체 장치별 시간 초과를 지정합니다.

pcmk_list_retries

integer

2

시간 초과 기간 내에 목록 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker 재시도 목록 작업을 포기하기 전에 목록 작업을 다시 시도한 횟수를 변경합니다.

pcmk_monitor_action

string

모니터

모니터 대신 실행할 대체 명령입니다. 일부 장치는 표준 명령을 지원하지 않거나 추가 명령을 제공할 수 있습니다. 이를 사용하여 모니터 작업을 구현하는 대체 장치별 명령을 지정합니다.

pcmk_monitor_timeout

time

60s

stonith-timeout 대신 모니터 작업에 사용할 대체 타임아웃을 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 모니터 작업에 대한 대체 장치별 시간 초과를 지정합니다.

pcmk_monitor_retries

integer

2

시간 초과 기간 내에 모니터 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker에서 해제하기 전에 모니터 작업을 재시도하는 횟수를 변경합니다.

pcmk_status_action

string

status

상태 대신 실행할 대체 명령입니다. 일부 장치는 표준 명령을 지원하지 않거나 추가 명령을 제공할 수 있습니다. 이를 사용하여 상태 작업을 구현하는 대체 장치별 명령을 지정합니다.

pcmk_status_timeout

time

60s

stonith-timeout 대신 상태 작업에 사용할 대체 타임아웃을 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 상태 작업에 대한 대체 장치별 시간 초과를 지정합니다.

pcmk_status_retries

integer

2

시간 제한 기간 내에 status 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker에서 종료하기 전에 상태 작업을 재시도하는 횟수를 변경합니다.

pcmk_delay_base

string

0s

펜싱 작업에 대한 기본 지연을 활성화하고 기본 지연 값을 지정합니다. pcmk_delay_base 매개변수를 사용하여 다른 노드에 대해 다른 값을 지정할 수 있습니다. 펜싱 지연 매개 변수 및 상호 작용에 대한 일반적인 정보는 지연 을 참조하십시오.

pcmk_delay_max

time

0s

펜싱 작업에 대한 임의의 지연을 활성화하고 결합된 기본 지연 및 임의 지연의 최대 값인 최대 지연을 지정합니다. 예를 들어 기본 지연이 3이고 pcmk_delay_max 가 10이면 임의 지연은 3에서 10 사이입니다. 펜싱 지연 매개 변수 및 상호 작용에 대한 일반적인 정보는 지연 을 참조하십시오.

pcmk_action_limit

integer

1

이 장치에서 병렬로 수행할 수 있는 최대 작업 수입니다. 클러스터 속성 concurrent-fencing=true 를 먼저 구성해야 합니다(기본값). 값 -1은 무제한입니다.

pcmk_on_action

string

On

고급 용도 전용의 경우: 에서 대신 실행할 대체 명령입니다. 일부 장치는 표준 명령을 지원하지 않거나 추가 명령을 제공할 수 있습니다. 이를 사용하여 on 작업을 구현하는 대체 장치별 명령을 지정합니다.

pcmk_on_timeout

time

60s

고급 용도 전용: stonith-timeout 대신 작업에 사용할 대체 타임아웃을 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 작업에 대한 대체 장치별 시간 초과를 지정합니다.

pcmk_on_retries

integer

2

고급 용도 전용: 시간 제한 기간 내에 on 명령을 다시 시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker 에서 작업을 중지하기 전에 재시도하는 횟수를 변경합니다.

개별 차단 장치에 대해 설정할 수 있는 속성 외에도 다음 표에 설명된 대로 펜싱 동작을 결정하는 클러스터 속성을 설정할 수도 있습니다.

Expand
표 4.3. 펜싱 동작을 결정하는 클러스터 속성
옵션Default설명

STONITH-enabled

true

중지할 수 없는 리소스가 있는 실패한 노드 및 노드를 펜싱해야 함을 나타냅니다. 데이터를 보호하려면 이 값을 설정해야 합니다.

true 또는 unset인 경우 하나 이상의 STONITH 리소스도 구성되지 않은 경우 클러스터는 리소스 시작을 거부합니다.

Red Hat은 이 값이 true 로 설정된 클러스터만 지원합니다.

STONITH-action

reboot

펜싱 장치에 전달할 작업입니다. 허용되는 값: reboot,off. poweroff 값도 허용되지만 레거시 장치에만 사용됩니다.

STONITH-timeout

60s

STONITH 작업이 완료될 때까지 대기하는 시간입니다.

stonith-max-attempts

10

클러스터가 더 이상 즉시 다시 시도하지 않기 전에 대상에 대해 펜싱이 실패할 수 있는 횟수입니다.

stonith-watchdog-timeout

 

노드가 하드웨어 워치독에 의해 종료되었다고 간주될 때까지 대기하는 최대 시간입니다. 이 값을 하드웨어 워치독 시간 제한의 두 배 값으로 설정하는 것이 좋습니다. 이 옵션은 워치독 전용 SBD 구성이 펜싱에 사용되는 경우에만 필요합니다.

concurrent-encing

true

펜싱 작업을 병렬로 수행할 수 있습니다.

fence-reaction

중지

자체 펜싱에 대한 알림을 받는 경우 클러스터 노드가 응답하는 방법을 결정합니다. 펜싱이 잘못 구성된 경우 클러스터 노드는 자체 펜싱에 대한 알림을 수신할 수 있습니다. 그렇지 않으면 클러스터 통신이 중단되지 않는 패브릭 펜싱을 사용하고 있습니다. 허용되는 값은 Pacemaker를 즉시 중지하고 중지된 상태를 유지하거나 로컬 노드를 즉시 재부팅하려고 시도하여 실패 시 다시 중지되도록 하는 것입니다.

이 속성의 기본값은 stop 이지만 이 값의 가장 안전한 선택은 panic 입니다. 이 경우 로컬 노드를 즉시 재부팅하려고 합니다. 중지 동작을 선호하는 경우 패브릭 펜싱과 함께 가장 가능성이 높은 경우 이 동작을 명시적으로 설정하는 것이 좋습니다.

priority-fencing-delay

0 (비활성화됨)

분할에서 가장 적은 리소스가 실행 중인 노드가 펜싱되는 노드가 펜싱되도록 2 노드 클러스터를 구성할 수 있는 펜싱 지연을 설정합니다. 펜싱 지연 매개 변수 및 상호 작용에 대한 일반적인 정보는 지연 을 참조하십시오.

클러스터 속성 설정에 대한 자세한 내용은 https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_high_availability_clusters/index#setting-cluster-properties을 참조하십시오.

4.5.4. 펜싱 지연

2-노드 클러스터에서 클러스터 통신이 손실되면 한 노드에서 먼저 이를 감지하고 다른 노드를 펜싱할 수 있습니다. 그러나 두 노드 모두 동시에 이를 감지하면 각 노드가 다른 노드의 펜싱을 시작하여 두 노드의 전원이 꺼지거나 재설정될 수 있습니다. 펜싱 지연을 설정하면 두 클러스터 노드가 서로 펜싱될 가능성을 줄일 수 있습니다. 두 개 이상의 노드가 있는 클러스터에서 지연을 설정할 수 있지만 쿼럼이 있는 파티션만 펜싱을 시작하기 때문에 일반적으로는 이점이 없습니다.

시스템 요구 사항에 따라 다양한 유형의 펜싱 지연을 설정할 수 있습니다.

  • 정적 펜싱 지연

    정적 펜싱 지연은 미리 정의된 고정된 지연입니다. 한 노드에 정적 지연을 설정하면 노드가 펜싱될 가능성이 높아집니다. 이로 인해 다른 노드가 통신 손실된 통신을 탐지한 후 먼저 펜싱을 시작할 가능성이 높아집니다. 활성/수동 클러스터에서 패시브 노드에서 지연을 설정하면 통신이 중단될 때 패시브 노드가 펜싱될 가능성이 높아집니다. pcs_delay_base 클러스터 속성을 사용하여 정적 지연을 구성합니다. 각 노드에 별도의 차단 장치를 사용하거나 모든 노드에 단일 차단 장치를 사용하는 경우 이 속성을 설정할 수 있습니다.

  • 동적 펜싱 지연

    동적 펜싱 지연은 임의적입니다. 이는 다를 수 있으며 펜싱 시에 결정됩니다. 임의의 지연을 구성하고 pcs_delay_max 클러스터 속성을 사용하여 결합된 기본 지연 및 임의의 지연을 지정합니다. 각 노드의 펜싱 지연이 임의적인 경우 펜싱되는 노드도 임의적입니다. 이 기능은 클러스터가 활성/활성 설계의 모든 노드에 대해 단일 차단 장치로 구성된 경우 유용할 수 있습니다.

  • 우선 순위 펜싱 지연

    우선 순위 펜싱 지연은 활성 리소스 우선 순위를 기반으로 합니다. 모든 리소스의 우선 순위가 동일한 경우 가장 적은 리소스가 실행되는 노드는 펜싱되는 노드입니다. 대부분의 경우 하나의 지연 관련 매개변수만 사용하지만 결합할 수 있습니다. 지연 관련 매개 변수를 결합하면 리소스의 우선 순위 값이 함께 추가되어 총 지연이 생성됩니다. priority-fencing-delay 클러스터 속성을 사용하여 우선순위 펜싱 지연을 구성합니다. 이 기능은 노드 간 통신이 손실될 때 가장 적은 리소스를 실행하는 노드가 차단될 수 있으므로 활성/활성 클러스터 설계에서 유용할 수 있습니다.

pcmk_delay_base 클러스터 속성

pcmk_delay_base 클러스터 속성을 설정하면 펜싱의 기본 지연이 활성화되고 기본 지연 값을 지정합니다.

pcmk_delay_max 클러스터 속성을 pcmk_delay_base 속성 외에도 설정할 때 전체 지연은 이 정적 지연에 추가된 임의의 지연 값에서 파생되어 합계가 최대 지연 아래로 유지됩니다. pcmk_delay_base 를 설정했지만 pcmk_delay_max 를 설정하지 않으면 지연에 임의의 구성 요소가 없으며 pcmk_delay_base 의 값이 됩니다.

pcmk_delay_base 매개변수를 사용하여 다른 노드에 대해 다른 값을 지정할 수 있습니다. 이를 통해 두 노드 클러스터에서 단일 펜스 장치를 사용할 수 있으며 각 노드에 대해 다른 지연이 발생합니다. 별도의 지연을 사용하도록 두 개의 개별 장치를 구성할 필요가 없습니다. 다른 노드에 대해 다른 값을 지정하려면 유사한 구문을 사용하여 pcmk_host_map 과 유사한 노드의 지연 값에 호스트 이름을 매핑합니다. 예를 들어 node1:0;node2:10s 는 node1을 펜싱할 때 지연 없이, node2 를 펜싱할 때 10초 지연을 사용합니다.

pcmk_delay_max 클러스터 속성

pcmk_delay_max 클러스터 속성을 설정하면 펜싱 작업에 대한 임의의 지연을 활성화하고 결합된 기본 지연 및 임의 지연의 최대 값인 최대 지연 시간을 지정합니다. 예를 들어 기본 지연이 3이고 pcmk_delay_max 가 10이면 임의 지연은 3에서 10 사이입니다.

pcmk_delay_base 클러스터 속성을 pcmk_delay_max 속성 외에도 설정할 때 전체 지연은 이 정적 지연에 추가된 임의의 지연 값에서 파생되어 합계가 최대 지연 아래로 유지됩니다. pcmk_delay_max 를 설정했지만 pcmk_delay_base 를 설정하지 않으면 지연에 대한 정적 구성 요소가 없습니다.

priority-fencing-delay 클러스터 속성

priority-fencing-delay 클러스터 속성을 설정하면 분할에서 가장 적은 리소스가 실행되는 노드가 펜싱되는 노드가 되도록 2-노드 클러스터를 구성할 수 있습니다.

priority-fencing-delay 속성은 시간 기간으로 설정할 수 있습니다. 이 속성의 기본값은 0입니다(비활성화됨). 이 속성이 0이 아닌 값으로 설정되고 우선 순위 meta-attribute가 하나 이상의 리소스에 대해 구성된 경우 분할에서 실행 중인 모든 리소스의 우선 순위가 가장 높은 노드가 작동 상태를 유지할 가능성이 더 높습니다. 예를 들어 pcs resource defaults update priority=1pcs 속성이 priority-fencing-delay=15s 를 설정하고 다른 우선순위가 설정되지 않은 경우 다른 노드가 펜싱을 시작하기 전에 15초를 기다리므로 대부분의 리소스를 실행하는 노드가 계속 작동할 가능성이 더 높습니다. 특정 리소스가 나머지 리소스보다 중요한 경우 우선 순위를 높일 수 있습니다.

승격 가능한 복제의 승격된 역할을 실행하는 노드는 해당 복제본에 대한 우선 순위가 구성된 경우 추가 1 포인트를 가져옵니다.

펜싱 지연의 상호 작용

펜싱 지연 유형을 두 개 이상 설정하면 다음과 같은 결과가 발생합니다.

  • priority-fencing-delay 속성으로 설정된 지연은 pcmk_delay_basepcmk_delay_max 차단 장치 속성의 지연에 추가됩니다. 이 동작은 on-fail=fencing 이 리소스 모니터 작업에 설정된 경우와 같이 노드 손실 이외의 이유로 두 노드를 모두 펜싱해야 하는 경우 두 노드를 모두 지연할 수 있습니다. 이러한 지연을 조합하여 설정할 때 priority-fencing-delay 속성을 pcmk_delay_basepcmk_delay_max 의 최대 지연보다 훨씬 큰 값으로 설정합니다. 이 속성을 두 번으로 설정하면 이 값은 항상 안전합니다.
  • Pacemaker 자체에서 예약한 펜싱만 펜싱 지연을 관찰합니다. dlm_controldpcs stonith fence 명령으로 구현된 펜싱과 같은 외부 코드에서 예약한 펜싱은 펜싱 장치에 필요한 정보를 제공하지 않습니다.
  • 일부 개별 차단 에이전트는 에이전트에 의해 결정되며 pcmk_delay_* 속성으로 구성된 지연과 관계없이 지연 매개 변수를 구현합니다. 이러한 두 지연이 모두 구성된 경우 함께 추가되며 일반적으로 함께 사용되지 않습니다.

4.5.5. 차단 장치 테스트

펜싱은 Red Hat Cluster 인프라의 기본 부분이며 펜싱이 제대로 작동하는지 검증하거나 테스트하는 것이 중요합니다.

참고

Pacemaker 클러스터 노드 또는 Pacemaker 원격 노드를 펜싱하는 경우 운영 체제를 정상적으로 종료하지 않고 하드 종료가 발생해야 합니다. 시스템이 노드를 펜싱할 때 정상 종료가 발생하면 /etc/systemd/logind.conf 파일에서 ACPI 소프트오프를 비활성화하여 시스템이 power-button-pressed 신호를 무시하도록 합니다. logind.conf 파일에서 ACPI 소프트오프를 비활성화하는 방법은 logind.conf 파일에서 ACPI 소프트오프 비활성화를 참조하십시오.

다음 절차를 사용하여 차단 장치를 테스트합니다.

프로세스

  1. SSH, Telnet, HTTP 또는 장치를 수동으로 로그인하고 테스트하거나 지정된 출력을 확인하는 데 사용되는 원격 프로토콜을 사용합니다. 예를 들어 IPMI 사용 장치에 대한 펜싱을 구성하는 경우 ipmitool 을 사용하여 원격으로 로그인합니다. 펜싱 에이전트를 사용할 때 이러한 옵션이 필요할 수 있으므로 수동으로 로그인할 때 사용되는 옵션을 기록해 두십시오.

    차단 장치에 로그인할 수 없는 경우 장치가 ping 가능한지 확인합니다. 이 방화벽 구성에서는 차단 장치에 대한 액세스를 방지하고 펜싱 장치에서 원격 액세스가 활성화되고 인증 정보가 올바른지 확인합니다.

  2. 차단 에이전트 스크립트를 사용하여 차단 에이전트를 수동으로 실행합니다. 이 작업을 수행하려면 클러스터에서 장치를 구성하기 전에 이 단계를 수행할 수 있도록 클러스터 서비스가 실행되고 있지 않습니다. 이렇게 하면 계속하기 전에 펜스 장치가 올바르게 응답하는지 확인할 수 있습니다.

    참고

    이러한 예에서는 iLO 장치에 fence_ipmilan 차단 에이전트 스크립트를 사용합니다. 사용할 실제 차단 에이전트와 해당 에이전트를 호출하는 명령은 서버 하드웨어에 따라 달라집니다. 지정할 옵션을 결정하려면 사용 중인 차단 에이전트의 도움말 페이지를 참조해야 합니다. 일반적으로 차단 장치의 로그인 및 암호 및 차단 장치와 관련된 기타 정보를 알아야 합니다.

    다음 예제에서는 실제로 펜싱하지 않고 다른 노드에서 차단 장치 인터페이스의 상태를 확인하기 위해 -o status 매개변수를 사용하여 fence_ipmilan 차단 에이전트 스크립트를 실행하는 데 사용하는 형식을 보여줍니다. 이를 통해 노드를 재부팅하기 전에 장치를 테스트하고 작동하게 할 수 있습니다. 이 명령을 실행하는 경우 iLO 장치에 대한 권한을 켜거나 끄는 iLO 사용자의 이름과 암호를 지정합니다.

    # fence_ipmilan -a ipaddress -l username -p password -o status
    Copy to Clipboard Toggle word wrap

    다음 예제에서는 -o reboot 매개변수를 사용하여 fence_ipmilan 차단 에이전트 스크립트를 실행하는 데 사용하는 형식을 보여줍니다. 한 노드에서 이 명령을 실행하면 이 iLO 장치에서 관리하는 노드가 재부팅됩니다.

    # fence_ipmilan -a ipaddress -l username -p password -o reboot
    Copy to Clipboard Toggle word wrap

    펜스 에이전트가 상태, 해제, on 또는 reboot 작업을 제대로 수행하지 못한 경우 하드웨어, 차단 장치 구성 및 명령의 구문을 확인해야 합니다. 또한 디버그 출력이 활성화된 상태에서 fence 에이전트 스크립트를 실행할 수 있습니다. 디버그 출력은 일부 펜싱 에이전트에서 차단 장치에 로그인할 때 펜싱 에이전트 스크립트가 실패하는지 확인하는 데 유용합니다.

    # fence_ipmilan -a ipaddress -l username -p password -o status -D /tmp/$(hostname)-fence_agent.debug
    Copy to Clipboard Toggle word wrap

    발생한 오류를 진단할 때 차단 장치에 수동으로 로그인할 때 지정한 옵션이 fence 에이전트 스크립트를 사용하여 차단 에이전트에 전달한 것과 동일한지 확인해야 합니다.

    암호화된 연결을 지원하는 차단 에이전트의 경우 인증서 유효성 검사 실패로 인한 오류가 표시될 수 있으며, 호스트를 신뢰하거나 차단 에이전트의 ssl-insecure 매개변수를 사용해야 할 수 있습니다. 마찬가지로 대상 장치에서 SSL/TLS가 비활성화된 경우 차단 에이전트의 SSL 매개변수를 설정할 때 이를 고려해야 할 수 있습니다.

    참고

    테스트 중인 펜스 에이전트가 계속 실패하는 시스템 관리 장치의 fence_drac,fence_ilo 또는 기타 일부 펜싱 에이전트인 경우 fence_ipmilan 을 다시 시도합니다. 대부분의 시스템 관리 카드는 IPMI 원격 로그인을 지원하며 지원되는 유일한 펜싱 에이전트는 fence_ipmilan 입니다.

  3. 다음 예와 같이 클러스터에서 작업하는 것과 동일한 옵션을 사용하여 클러스터에서 차단 장치를 구성한 후 모든 노드에서 pcs stonith fence 명령을 사용하여 펜싱을 테스트합니다(또는 다른 노드에서 여러 번). pcs stonith fence 명령은 CIB에서 클러스터 구성을 읽고 fence 작업을 실행하도록 구성된 fence 에이전트를 호출합니다. 이렇게 하면 클러스터 구성이 올바른지 확인합니다.

    # pcs stonith fence node_name
    Copy to Clipboard Toggle word wrap

    pcs stonith fence 명령이 제대로 작동하는 경우 차단 이벤트가 발생할 때 클러스터의 펜싱 구성이 작동해야 합니다. 명령이 실패하면 클러스터 관리가 검색한 구성을 통해 차단 장치를 호출할 수 없음을 의미합니다. 다음 문제를 확인하고 필요에 따라 클러스터 구성을 업데이트합니다.

    • 펜스 구성을 확인합니다. 예를 들어 호스트 맵을 사용한 경우 시스템에서 제공한 호스트 이름을 사용하여 노드를 찾을 수 있는지 확인해야 합니다.
    • 장치의 암호 및 사용자 이름에 bash 쉘에서 잘못 해석할 수 있는 특수 문자가 포함되어 있는지 확인합니다. 따옴표로 묶은 암호와 사용자 이름을 입력했는지 확인하면 이 문제를 해결할 수 있습니다.
    • pcs stonith 명령에 지정한 정확한 IP 주소 또는 호스트 이름을 사용하여 장치에 연결할 수 있는지 확인합니다. 예를 들어 stonith 명령에 호스트 이름을 지정하지만 IP 주소를 사용하여 테스트하는 경우 유효한 테스트가 아닙니다.
    • 펜스 장치에서 사용하는 프로토콜에 액세스할 수 있는 경우 해당 프로토콜을 사용하여 장치에 연결을 시도합니다. 예를 들어 많은 에이전트가 ssh 또는 telnet을 사용합니다. 장치를 구성할 때 제공한 인증 정보를 사용하여 장치에 연결을 시도하여 유효한 프롬프트가 표시되는지 확인하고 장치에 로그인할 수 있습니다.

      모든 매개변수가 적합하지만 차단 장치에 연결하는 데 문제가 있는 경우 장치가 이를 제공하는 경우 사용자가 연결된 명령과 사용자가 실행한 명령을 표시하는 경우 차단 장치 자체에서 로깅을 확인할 수 있습니다. 또한 /var/log/messages 파일을 통해 stonith 및 error 인스턴스를 검색할 수 있으며 이로 인해 전송되는 내용에 대한 아이디어를 제공할 수 있지만 일부 에이전트는 추가 정보를 제공할 수 있습니다.

  4. 펜스 장치 테스트가 작동하고 클러스터가 가동되어 실행되면 실제 실패를 테스트합니다. 이렇게 하려면 토큰 손실을 시작해야 하는 클러스터에서 작업을 수행합니다.

    • 네트워크를 끕니다. 네트워크를 사용하는 방법은 특정 구성에 따라 다릅니다. 대부분의 경우 호스트에서 네트워크 또는 전원 케이블을 물리적으로 끌어올 수 있습니다. 네트워크 장애 시뮬레이션에 대한 자세한 내용은 RHEL 클러스터에서 네트워크 오류를 시뮬레이션하는 적절한 방법은 무엇입니까?

      참고

      일반적인 실제 장애를 정확하게 시뮬레이션하지 않기 때문에 네트워크 또는 전원 케이블을 물리적으로 연결 해제하지 않고 로컬 호스트에서 네트워크 인터페이스를 비활성화하는 것은 펜싱 테스트로 권장되지 않습니다.

    • 로컬 방화벽을 사용하는 인바운드 및 아웃바운드 블록 corosync 트래픽입니다.

      다음 예제 블록 corosync 기본 corosync 포트가 사용되면 firewalld 는 로컬 방화벽으로 사용되며 corosync에서 사용하는 네트워크 인터페이스는 기본 방화벽 영역에 있습니다.

      # firewall-cmd --direct --add-rule ipv4 filter OUTPUT 2 -p udp --dport=5405 -j DROP
      # firewall-cmd --add-rich-rule='rule family="ipv4" port port="5405" protocol="udp" drop
      Copy to Clipboard Toggle word wrap
    • sysrq-trigger 를 사용하여 크래시를 시뮬레이션하고 시스템에 패닉을 발생시킵니다. 그러나 커널 패닉을 트리거하면 데이터가 손실될 수 있습니다. 먼저 클러스터 리소스를 비활성화하는 것이 좋습니다.

      # echo c > /proc/sysrq-trigger
      Copy to Clipboard Toggle word wrap

4.5.6. 펜싱 수준 구성

Pacemaker에서는 펜싱 토폴로지라는 기능을 통해 여러 장치가 있는 노드 펜싱을 지원합니다. 토폴로지를 구현하려면 일반적으로 개별 장치를 생성한 다음 구성의 펜싱 토폴로지 섹션에 하나 이상의 펜싱 수준을 정의합니다.

Pacemaker는 다음과 같이 펜싱 수준을 처리합니다.

  • 각 수준은 1부터 오름차순으로 오름차순으로 시도됩니다.
  • 장치가 실패하면 현재 수준에 대한 처리가 종료됩니다. 해당 수준의 추가 장치가 수행되지 않으며 다음 수준이 대신 시도됩니다.
  • 모든 장치가 성공적으로 펜싱되면 해당 수준이 성공했으며 다른 수준은 시도하지 않습니다.
  • 수준이 통과(성공)되거나 모든 수준을 시도한 경우 작업이 완료됩니다(실패).

다음 명령을 사용하여 노드에 펜싱 수준을 추가합니다. 장치는 해당 수준에서 노드에 대해 시도되는 쉼표로 구분된 stonith ids 목록으로 제공됩니다.

pcs stonith level add level node devices
Copy to Clipboard Toggle word wrap

다음 예제에서는 장치 my_ilo 가 실패하고 노드를 펜싱할 수 없는 경우 Pacemaker에서 my_apc 장치를 사용하려고 시도하도록 차단 수준을 설정합니다.

사전 요구 사항

  • rh7-2 노드에 대해 my_ilo 라는 ilo fence 장치를 구성했습니다.
  • rh7-2 노드에 대해 my_apc 라는 apc 차단 장치를 구성했습니다.

프로세스

  1. rh7-2 노드에서 my_ilo 차단 장치에 대해 1의 펜싱 수준을 추가합니다.

    # pcs stonith level add 1 rh7-2 my_ilo
    Copy to Clipboard Toggle word wrap
  2. rh7-2 노드에서 차단 장치 my_apc 에 대해 2의 펜싱 수준을 추가합니다.

    # pcs stonith level add 2 rh7-2 my_apc
    Copy to Clipboard Toggle word wrap
  3. 현재 구성된 펜싱 수준을 나열합니다.

    # pcs stonith level
     Node: rh7-2
      Level 1 - my_ilo
      Level 2 - my_apc
    Copy to Clipboard Toggle word wrap

노드 속성에 대한 자세한 내용은 https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/configuring_and_managing_high_availability_clusters/index#node-attributes을 참조하십시오.

4.5.7. 차단 수준 제거

지정된 노드 및 장치의 펜스 수준을 제거할 수 있습니다. 노드 또는 장치를 지정하지 않으면 지정한 차단 수준이 모든 노드에서 제거됩니다.

프로세스

  • 지정된 노드 및 장치의 펜스 수준을 제거합니다.

    # pcs stonith level remove level [node_id] [stonith_id] ... [stonith_id]
    Copy to Clipboard Toggle word wrap

4.5.8. 펜스 수준 삭제

지정된 노드 또는 stonith ID에서 펜스 수준을 지울 수 있습니다. 노드 또는 stonith ID를 지정하지 않으면 모든 차단 수준이 지워집니다.

프로세스

  • 지정된 노드 또는 stinith id에서 fence 수준을 지웁니다.

    # pcs stonith level clear [node]|stonith_id(s)]
    Copy to Clipboard Toggle word wrap
  • 다음 예제와 같이 두 개 이상의 stonith ID를 쉼표로 구분하고 공백을 사용하지 않아야 합니다.

    # pcs stonith level clear dev_a,dev_b
    Copy to Clipboard Toggle word wrap

4.5.9. 차단 수준에서 노드 및 장치 확인

fence 수준에 지정된 모든 차단 장치 및 노드가 있는지 확인할 수 있습니다.

프로세스

  • 다음 명령을 사용하여 fence 수준에 지정된 모든 차단 장치 및 노드가 있는지 확인합니다.

    # pcs stonith level verify
    Copy to Clipboard Toggle word wrap

4.5.10. 펜싱 토폴로지에서 노드 지정

노드 이름 및 해당 값에 적용되는 정규식으로 펜싱 토폴로지의 노드를 지정할 수 있습니다.

프로세스

  • 다음 명령은 노드 node1,node2node3 을 구성하여 차단 장치 apc1apc2, node4 , node4,node5, node6 을 사용하여 차단 장치 apc3apc4 를 사용합니다.

    # pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2
    # pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4
    Copy to Clipboard Toggle word wrap
  • 다음 명령은 노드 특성 일치를 사용하여 동일한 결과를 제공합니다.

    # pcs node attribute node1 rack=1
    # pcs node attribute node2 rack=1
    # pcs node attribute node3 rack=1
    # pcs node attribute node4 rack=2
    # pcs node attribute node5 rack=2
    # pcs node attribute node6 rack=2
    # pcs stonith level add 1 attrib%rack=1 apc1,apc2
    # pcs stonith level add 1 attrib%rack=2 apc3,apc4
    Copy to Clipboard Toggle word wrap

4.5.11. 중복 전원 공급 장치를 위한 펜싱 구성

중복 전원 공급 장치를 구성할 때 클러스터에서 호스트 재부팅을 시도할 때 두 전원 공급 장치를 모두 꺼야 전원 공급 장치를 다시 켜야 합니다.

노드의 전원이 완전히 손실되지 않으면 노드에서 해당 리소스를 해제하지 못할 수 있습니다. 이렇게 하면 노드가 이러한 리소스에 동시에 액세스하고 손상될 수 있습니다.

각 장치를 한 번만 정의하고 노드를 펜싱하는 데 둘 다 필요함을 지정해야 합니다.

프로세스

  1. 첫 번째 차단 장치를 생성합니다.

    # pcs stonith create apc1 fence_apc_snmp ipaddr=apc1.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"
    Copy to Clipboard Toggle word wrap
  2. 두 번째 차단 장치를 생성합니다.

    # pcs stonith create apc2 fence_apc_snmp ipaddr=apc2.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"
    Copy to Clipboard Toggle word wrap
  3. 노드를 펜싱하는 데 두 장치가 모두 필요하므로 지정합니다.

    # pcs stonith level add 1 node1.example.com apc1,apc2
    # pcs stonith level add 1 node2.example.com apc1,apc2
    Copy to Clipboard Toggle word wrap

4.5.12. 차단 장치 관리

pcs 명령줄 인터페이스는 차단 장치를 구성한 후 사용할 수 있는 다양한 명령을 제공합니다.

4.5.12.1. 구성된 차단 장치 표시

다음 명령은 현재 구성된 모든 차단 장치를 보여줍니다. stonith_id 가 지정된 경우 명령은 구성된 펜싱 장치에 대한 옵션만 표시합니다. --full 옵션을 지정하면 구성된 모든 펜싱 옵션이 표시됩니다.

pcs stonith config [stonith_id] [--full]
Copy to Clipboard Toggle word wrap
4.5.12.2. fence 장치 를 pcs 명령으로 내보내기

pcs stonith config 명령의 --output-format=cmd 옵션을 사용하여 다른 시스템에서 구성된 펜스 장치를 다시 생성하는 데 사용할 수 있는 pcs 명령을 표시할 수 있습니다.

다음 명령은 fence_apc_snmp 차단 장치를 생성하고 장치를 다시 생성하는 데 사용할 수 있는 pcs 명령을 표시합니다.

# pcs stonith create myapc fence_apc_snmp ip="zapc.example.com" pcmk_host_map="z1.example.com:1;z2.example.com:2" username="apc" password="apc"
# pcs stonith config --output-format=cmd
Warning: Only 'text' output format is supported for stonith levels
pcs stonith create --no-default-ops --force -- myapc fence_apc_snmp \
  ip=zapc.example.com password=apc 'pcmk_host_map=z1.example.com:1;z2.example.com:2' username=apc \
  op \
    monitor interval=60s id=myapc-monitor-interval-60s
Copy to Clipboard Toggle word wrap
4.5.12.3. 차단 수준 구성 내보내기

pcs stonith 구성pcs stonith 수준 구성 명령은 --output-format= 옵션을 지원하여 펜싱 수준 구성을 JSON 형식 및 pcs 명령으로 내보냅니다.

  • --output-format=cmd 를 지정하면 펜싱 수준을 구성하는 현재 클러스터 구성에서 생성된 pcs 명령이 표시됩니다. 이러한 명령을 사용하여 다른 시스템에서 구성된 펜싱 수준을 다시 생성할 수 있습니다.
  • --output-format=json 을 지정하면 시스템 구문 분석에 적합한 펜싱 수준 구성이 JSON 형식으로 표시됩니다.
4.5.12.4. 차단 장치 수정 및 삭제

다음 명령을 사용하여 현재 구성된 펜싱 장치에 옵션을 수정하거나 추가합니다.

pcs stonith update stonith_id [stonith_device_options]
Copy to Clipboard Toggle word wrap

pcs stonith update 명령을 사용하여 SCSI 펜싱 장치를 업데이트하면 펜싱 리소스가 실행 중인 동일한 노드에서 실행되는 모든 리소스가 다시 시작됩니다. 다음 명령의 두 버전을 사용하여 다른 클러스터 리소스를 재시작하지 않고 SCSI 장치를 업데이트할 수 있습니다. SCSI 펜싱 장치는 다중 경로 장치로 구성할 수 있습니다.

pcs stonith update-scsi-devices stonith_id set device-path1 device-path2
pcs stonith update-scsi-devices stonith_id add device-path1 remove device-path2
Copy to Clipboard Toggle word wrap

다음 명령을 사용하여 현재 구성에서 펜싱 장치를 제거합니다.

pcs stonith delete stonith_id
Copy to Clipboard Toggle word wrap
4.5.12.5. 수동으로 클러스터 노드 펜싱

다음 명령을 사용하여 노드를 수동으로 펜싱할 수 있습니다. --off 옵션을 지정하면 off API 호출을 사용하여 stonith를 사용하여 노드를 재부팅하지 않고 꺼집니다.

pcs stonith fence node [--off]
Copy to Clipboard Toggle word wrap

펜스 장치가 더 이상 활성 상태가 아니더라도 노드를 펜싱할 수 없는 경우 클러스터는 노드의 리소스를 복구하지 못할 수 있습니다. 이 경우 노드의 전원이 꺼졌는지 수동으로 확인한 후 다음 명령을 입력하여 노드의 전원이 꺼졌는지 확인하고 복구를 위해 해당 리소스를 해제할 수 있습니다.

주의

지정한 노드가 실제로 꺼져 있지 않지만 클러스터에 의해 일반적으로 제어되는 클러스터 소프트웨어 또는 서비스를 실행하면 데이터 손상 및 클러스터 오류가 발생합니다.

pcs stonith confirm node
Copy to Clipboard Toggle word wrap
4.5.12.6. 차단 장치 비활성화

펜싱 장치를 비활성화하려면 pcs stonith disable 명령을 실행합니다.

다음 명령은 차단 장치 myapc 를 비활성화합니다.

# pcs stonith disable myapc
Copy to Clipboard Toggle word wrap
4.5.12.7. 노드에서 펜싱 장치를 사용하지 못하도록 방지

특정 노드가 펜싱 장치를 사용하지 않도록 하려면 펜싱 리소스의 위치 제약 조건을 구성할 수 있습니다.

다음 예제에서는 fence 장치 node1-ipminode1 에서 실행되지 않도록 합니다.

# pcs constraint location node1-ipmi avoids node1
Copy to Clipboard Toggle word wrap

4.5.13. 통합 펜스 장치와 함께 사용할 ACPI 구성

클러스터에서 통합 펜스 장치를 사용하는 경우 즉시 펜싱을 완료하도록 ACPI(고급 구성 및 전원 인터페이스)를 구성해야 합니다.

클러스터 노드가 통합 차단 장치에 의해 펜싱되도록 구성된 경우 해당 노드에 대해 ACPI Soft-Off를 비활성화합니다. ACPI soft-Off를 비활성화하면 통합 차단 장치가 완전히 종료를 시도하지 않고 노드를 즉시 끌 수 있습니다(예: shutdown -h now). 그렇지 않으면 ACPI Soft-Off가 활성화된 경우 통합 차단 장치가 노드를 끄는 데 4초 이상 걸릴 수 있습니다(다음 참고 사항 참조). 또한 ACPI Soft-Off가 활성화되고 종료 중에 노드가 패닉되거나 정지되면 통합 차단 장치가 노드를 끄지 못할 수 있습니다. 이러한 상황에서는 펜싱이 지연되거나 실패합니다. 결과적으로 통합 차단 장치로 노드를 펜싱하고 ACPI Soft-Off가 활성화되면 클러스터는 느리게 복구되거나 복구하기 위해 관리 개입이 필요합니다.

참고

노드를 펜싱하는 데 필요한 시간은 사용된 통합 차단 장치에 따라 다릅니다. 일부 통합 차단 장치는 전원 버튼을 누른 상태에서 유지하는 것과 동등한 작업을 수행하므로 차단 장치가 4~5초 내에 노드를 끕니다. 다른 통합 차단 장치는 일시적으로 전원 버튼을 누르면서 운영 체제에 따라 노드를 끄는 것과 동일한 작업을 수행합니다. 따라서 차단 장치는 4~5초보다 훨씬 더 긴 시간 내에 노드를 끕니다.

  • ACPI Soft-Off를 비활성화하는 기본 방법은 BIOS 설정을 "instant-off" 또는 BIOS 설정을 "instant-off"로 변경하는 것입니다. 이는 BIOS 설정을 BIOS 설정을 "instant -off"로 변경하는 것입니다.

BIOS로 ACPI Soft-Off를 비활성화하면 일부 시스템에서 가능하지 않을 수 있습니다. BIOS로 ACPI Soft-Off를 비활성화하면 클러스터에 대한 불만이 없는 경우 다음 대체 방법 중 하나를 사용하여 ACPI Soft-Off를 비활성화할 수 있습니다.

4.5.13.1. BIOS로 ACPI soft-Off 비활성화

다음 절차에 따라 각 클러스터 노드의 BIOS를 구성하여 ACPI Soft-Off를 비활성화할 수 있습니다.

참고

BIOS로 ACPI Soft-Off를 비활성화하는 절차는 서버 시스템마다 다를 수 있습니다. 하드웨어 설명서에서 이 절차를 확인해야 합니다.

프로세스

  1. 노드를 재부팅하고 BIOS CMOS 설정 유틸리티 프로그램을 시작합니다.
  2. Power 메뉴(또는 동등한 전원 관리 메뉴)로 이동합니다.
  3. Power 메뉴에서 PWR-BTTN 함수(또는 이에 해당하는 경우)를 Instant-Off 로 설정합니다(또는 지연 없이 전원 버튼을 사용하여 노드를 끄는 동등한 설정). 아래 BIOS CMOS 설정 사용률 예제에는 PWR-BTTN이 Instant-Off 로 설정된 ACPI FunctionEnabled 로 설정된 Power 메뉴가 표시되어 있습니다.

    참고

    ACPI 기능,PWR-BTTN에 의한 soft-Off에 해당하는 것으로, Instant-Off 는 컴퓨터마다 다를 수 있습니다. 그러나 이 절차의 목적은 컴퓨터를 지연 없이 전원 버튼을 통해 꺼지도록 BIOS를 구성하는 것입니다.

  4. BIOS CMOS 설정 유틸리티 프로그램을 종료하고 BIOS 구성을 저장합니다.
  5. 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.

BIOS CMOS 설정 유틸리티:

`Soft-Off by PWR-BTTN` set to
`Instant-Off`
Copy to Clipboard Toggle word wrap

+---------------------------------------------|-------------------+
|    ACPI Function             [Enabled]      |    Item Help      |
|    ACPI Suspend Type         [S1(POS)]      |-------------------|
|  x Run VGABIOS if S3 Resume   Auto          |   Menu Level   *  |
|    Suspend Mode              [Disabled]     |                   |
|    HDD Power Down            [Disabled]     |                   |
|    Soft-Off by PWR-BTTN      [Instant-Off   |                   |
|    CPU THRM-Throttling       [50.0%]        |                   |
|    Wake-Up by PCI card       [Enabled]      |                   |
|    Power On by Ring          [Enabled]      |                   |
|    Wake Up On LAN            [Enabled]      |                   |
|  x USB KB Wake-Up From S3     Disabled      |                   |
|    Resume by Alarm           [Disabled]     |                   |
|  x  Date(of Month) Alarm       0            |                   |
|  x  Time(hh:mm:ss) Alarm       0 :  0 :     |                   |
|    POWER ON Function         [BUTTON ONLY   |                   |
|  x KB Power ON Password       Enter         |                   |
|  x Hot Key Power ON           Ctrl-F1       |                   |
|                                             |                   |
|                                             |                   |
+---------------------------------------------|-------------------+
Copy to Clipboard Toggle word wrap

이 예에서는 ACPI FunctionEnabled 로 설정되고 PWR-BTTN이 Instant-Off 로 설정된 soft -Off를 보여줍니다.

4.5.13.2. logind.conf 파일에서 ACPI soft-Off 비활성화

/etc/systemd/logind.conf 파일에서 전원 키 전달을 비활성화하려면 다음 절차를 사용하십시오.

프로세스

  1. /etc/systemd/logind.conf 파일에 다음 구성을 정의합니다.

    HandlePowerKey=ignore
    Copy to Clipboard Toggle word wrap
  2. systemd-logind 서비스를 다시 시작하십시오.

    # systemctl restart systemd-logind.service
    Copy to Clipboard Toggle word wrap

검증

  1. 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.
4.5.13.3. GRUB 2 파일에서 ACPI를 완전히 비활성화

커널의 GRUB 메뉴 항목에 acpi=off 를 추가하여 ACPI Soft-Off를 비활성화할 수 있습니다.

중요

이 방법은 ACPI를 완전히 비활성화합니다. ACPI를 완전히 비활성화하면 일부 컴퓨터가 올바르게 부팅되지 않습니다. 다른 방법이 클러스터에 효과가 없는 경우에만 이 방법을 사용합니다.

프로세스

  1. grubby 툴의 --update-kernel 옵션과 함께 --args 옵션을 사용하여 다음과 같이 각 클러스터 노드의 grub.cfg 파일을 변경합니다.

    # grubby --args=acpi=off --update-kernel=ALL
    Copy to Clipboard Toggle word wrap
  2. 노드를 재부팅합니다.

검증

  1. 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 차단 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.

4.6. Azure 내부 로드 밸런서 생성

Azure 내부 로드 밸런서는 상태 프로브 요청에 응답하지 않는 클러스터 노드를 제거합니다. 다음 절차에는 특정 Microsoft 절차를 참조하는 각 단계가 있으며 HA에 대한 로드 밸런서를 사용자 정의하는 설정이 포함됩니다.

사전 요구 사항

프로세스

  1. 기본 로드 밸런서를 생성합니다. IP 주소 할당 유형으로 Internal load balancer, Basic SKU, Dynamic 을 선택합니다.
  2. 백엔드 주소 풀을 만듭니다. HA에서 Azure 리소스를 생성하는 동안 생성된 가용성 집합에 백엔드 풀을 연결합니다. 대상 네트워크 IP 구성을 설정하지 마십시오.
  3. 상태 프로브를 생성합니다. 상태 프로브의 경우 TCP를 선택하고 포트 61000을 입력합니다. 다른 서비스를 방해하지 않는 TCP 포트 번호를 사용할 수 있습니다. 특정 HA 제품 애플리케이션(예: SAP HANA 및 SQL Server)의 경우 사용할 올바른 포트를 식별하기 위해 Microsoft로 작업해야 할 수 있습니다.
  4. 로드 밸런서 규칙을 생성합니다. 부하 분산 규칙을 생성하려면 기본값이 미리 채워집니다. 유동 IP(직접 서버 반환)Enabled 로 설정해야 합니다.

4.7. 로드 밸런서 리소스 에이전트 구성

상태 프로브를 생성한 후 로드 밸런서 리소스 에이전트를 구성해야 합니다. 이 리소스 에이전트는 Azure 로드 밸런서의 상태 프로브 요청에 응답하는 서비스를 실행하고 요청을 응답하지 않는 클러스터 노드를 제거합니다.

사전 요구 사항

프로세스

  1. 모든 노드에 nmap-ncat 리소스 에이전트를 설치합니다.

    # dnf install nmap-ncat resource-agents-cloud
    Copy to Clipboard Toggle word wrap
  2. 단일 노드에서 다음 단계를 수행합니다.

    1. IPaddr2 주소에 대해 FrontendIP 로드 밸런서를 사용하여 pcs 리소스 및 그룹을 생성합니다.

      # pcs resource create resource-name IPaddr2 ip="10.0.0.7" --group <cluster_resources_group>
      Copy to Clipboard Toggle word wrap
    2. 로드 밸런서 리소스 에이전트를 구성합니다.

      # pcs resource create resource-loadbalancer-name azure-lb port=port-number --group <cluster_resources_group>
      Copy to Clipboard Toggle word wrap

검증

  • pcs status를 실행하여 결과를 확인합니다.

    [root@node01 clouduser]# pcs status
    
    Cluster name: clusterfence01
    Stack: corosync
    Current DC: node02 (version 1.1.16-12.el7_4.7-94ff4df) - partition with quorum
    Last updated: Tue Jan 30 12:42:35 2018
    Last change: Tue Jan 30 12:26:42 2018 by root via cibadmin on node01
    
    3 nodes configured
    3 resources configured
    
    Online: [ node01 node02 node03 ]
    
    Full list of resources:
    
    clusterfence (stonith:fence_azure_arm):      Started node01
    Resource Group: g_azure
        vip_azure  (ocf::heartbeat:IPaddr2):       Started node02
        lb_azure   (ocf::heartbeat:azure-lb):      Started node02
    
    Daemon Status:
      corosync: active/disabled
      pacemaker: active/disabled
      pcsd: active/enabled
    Copy to Clipboard Toggle word wrap

4.8. 공유 블록 스토리지 구성

Microsoft Azure Shared Disks를 사용하여 Red Hat High Availability 클러스터에 대한 공유 블록 스토리지를 구성하려면 다음 절차를 사용하십시오. 이 절차는 선택 사항입니다.

참고

이는 블록 스토리지를 구성하기 위한 독립 실행형 샘플 절차입니다. 이 절차에서는 클러스터를 아직 생성하지 않은 것으로 가정합니다.

사전 요구 사항

프로세스

  1. 공유 블록 볼륨 을 생성합니다.

    $ az disk create -g <resource_group> -n <shared_block_volume_name> --size-gb <disk_size> --max-shares <number_vms> -l <location>
    Copy to Clipboard Toggle word wrap

    예를 들어 다음 명령은 Azure 가용성 영역 westcentralus 의 리소스 그룹 sharedblockshared-block-volume.vhd 라는 공유 블록 볼륨을 생성합니다.

    $ az disk create -g sharedblock-rg -n shared-block-volume.vhd --size-gb 1024 --max-shares 3 -l westcentralus
    
    {
      "creationData": {
        "createOption": "Empty",
        "galleryImageReference": null,
        "imageReference": null,
        "sourceResourceId": null,
        "sourceUniqueId": null,
        "sourceUri": null,
        "storageAccountId": null,
        "uploadSizeBytes": null
      },
      "diskAccessId": null,
      "diskIopsReadOnly": null,
      "diskIopsReadWrite": 5000,
      "diskMbpsReadOnly": null,
      "diskMbpsReadWrite": 200,
      "diskSizeBytes": 1099511627776,
      "diskSizeGb": 1024,
      "diskState": "Unattached",
      "encryption": {
        "diskEncryptionSetId": null,
        "type": "EncryptionAtRestWithPlatformKey"
      },
      "encryptionSettingsCollection": null,
      "hyperVgeneration": "V1",
      "id": "/subscriptions/12345678910-12345678910/resourceGroups/sharedblock-rg/providers/Microsoft.Compute/disks/shared-block-volume.vhd",
      "location": "westcentralus",
      "managedBy": null,
      "managedByExtended": null,
      "maxShares": 3,
      "name": "shared-block-volume.vhd",
      "networkAccessPolicy": "AllowAll",
      "osType": null,
      "provisioningState": "Succeeded",
      "resourceGroup": "sharedblock-rg",
      "shareInfo": null,
      "sku": {
        "name": "Premium_LRS",
        "tier": "Premium"
      },
      "tags": {},
      "timeCreated": "2020-08-27T15:36:56.263382+00:00",
      "type": "Microsoft.Compute/disks",
      "uniqueId": "cd8b0a25-6fbe-4779-9312-8d9cbb89b6f2",
      "zones": null
    }
    Copy to Clipboard Toggle word wrap
  2. 공유 블록 볼륨 을 확인합니다.

    $ az disk show -g <resource_group> -n <shared_block_volume_name>
    Copy to Clipboard Toggle word wrap

    예를 들어 다음 명령은 리소스 그룹 sharedblock-rg 내에 공유 블록 볼륨 shared-block-volume.vhd 에 대한 세부 정보를 보여줍니다.

    $ az disk show -g sharedblock-rg -n shared-block-volume.vhd
    
    {
      "creationData": {
        "createOption": "Empty",
        "galleryImageReference": null,
        "imageReference": null,
        "sourceResourceId": null,
        "sourceUniqueId": null,
        "sourceUri": null,
        "storageAccountId": null,
        "uploadSizeBytes": null
      },
      "diskAccessId": null,
      "diskIopsReadOnly": null,
      "diskIopsReadWrite": 5000,
      "diskMbpsReadOnly": null,
      "diskMbpsReadWrite": 200,
      "diskSizeBytes": 1099511627776,
      "diskSizeGb": 1024,
      "diskState": "Unattached",
      "encryption": {
        "diskEncryptionSetId": null,
        "type": "EncryptionAtRestWithPlatformKey"
      },
      "encryptionSettingsCollection": null,
      "hyperVgeneration": "V1",
      "id": "/subscriptions/12345678910-12345678910/resourceGroups/sharedblock-rg/providers/Microsoft.Compute/disks/shared-block-volume.vhd",
      "location": "westcentralus",
      "managedBy": null,
      "managedByExtended": null,
      "maxShares": 3,
      "name": "shared-block-volume.vhd",
      "networkAccessPolicy": "AllowAll",
      "osType": null,
      "provisioningState": "Succeeded",
      "resourceGroup": "sharedblock-rg",
      "shareInfo": null,
      "sku": {
        "name": "Premium_LRS",
        "tier": "Premium"
      },
      "tags": {},
      "timeCreated": "2020-08-27T15:36:56.263382+00:00",
      "type": "Microsoft.Compute/disks",
      "uniqueId": "cd8b0a25-6fbe-4779-9312-8d9cbb89b6f2",
      "zones": null
    }
    Copy to Clipboard Toggle word wrap
  3. 세 개의 네트워크 인터페이스를 만듭니다. 각 노드에 다른 < nic_name> 을 사용하여 다음 명령을 세 번 실행합니다.

    $ az network nic create \
        -g <resource_group> -n <nic_name> --subnet <subnet_name> \
        --vnet-name <virtual_network> --location <location> \
        --network-security-group <network_security_group> --private-ip-address-version IPv4
    Copy to Clipboard Toggle word wrap

    예를 들어 다음 명령은 이름이 shareblock-nodea-vm-nic-protected 인 네트워크 인터페이스를 만듭니다.

    $ az network nic create \
        -g sharedblock-rg -n sharedblock-nodea-vm-nic-protected --subnet sharedblock-subnet-protected \
        --vnet-name sharedblock-vn --location westcentralus \
        --network-security-group sharedblock-nsg --private-ip-address-version IPv4
    Copy to Clipboard Toggle word wrap
  4. 세 개의 VM을 생성하고 공유 블록 볼륨을 연결합니다. 옵션 값은 각 VM에 자체 <vm_name> , < new _vm_disk_name > , 및 < nic_name > :이 있다는 점을 제외하고 각 VM에 대해 동일합니다.

    $ az vm create \
        -n <vm_name> -g <resource_group> --attach-data-disks <shared_block_volume_name> \
        --data-disk-caching None --os-disk-caching ReadWrite --os-disk-name <new_vm_disk_name> \
        --os-disk-size-gb <disk_size> --location <location> --size <virtual_machine_size> \
        --image <image_name> --admin-username <vm_username> --authentication-type ssh \
        --ssh-key-values <ssh_key> --nics <nic_name> --availability-set <availability_set> --ppg <proximity_placement_group>
    Copy to Clipboard Toggle word wrap

    예를 들어 다음 명령은 sharedblock-nodea-vm 이라는 VM을 생성합니다.

    $ az vm create \
    -n sharedblock-nodea-vm -g sharedblock-rg --attach-data-disks shared-block-volume.vhd \
    --data-disk-caching None --os-disk-caching ReadWrite --os-disk-name sharedblock-nodea-vm.vhd \
    --os-disk-size-gb 64 --location westcentralus --size Standard_D2s_v3 \
    --image /subscriptions/12345678910-12345678910/resourceGroups/sample-azureimagesgroupwestcentralus/providers/Microsoft.Compute/images/sample-azure-rhel-10.3.0-20200713.n.0.x86_64 --admin-username sharedblock-user --authentication-type ssh \
    --ssh-key-values @sharedblock-key.pub --nics sharedblock-nodea-vm-nic-protected --availability-set sharedblock-as --ppg sharedblock-ppg
    
    {
      "fqdns": "",
      "id": "/subscriptions/12345678910-12345678910/resourceGroups/sharedblock-rg/providers/Microsoft.Compute/virtualMachines/sharedblock-nodea-vm",
      "location": "westcentralus",
      "macAddress": "00-22-48-5D-EE-FB",
      "powerState": "VM running",
      "privateIpAddress": "198.51.100.3",
      "publicIpAddress": "",
      "resourceGroup": "sharedblock-rg",
      "zones": ""
    }
    Copy to Clipboard Toggle word wrap

검증

  1. 클러스터의 각 VM에 대해 블록 장치를 사용할 수 있는지 확인합니다. 이렇게 하려면 VM의 IP 주소와 함께 ssh 명령을 사용하여 vm에 연결합니다.

    # ssh <ip_address> "hostname ; lsblk -d | grep ' 1T '"
    Copy to Clipboard Toggle word wrap

    예를 들어 다음 명령은 VM IP 198.51.100.3 의 호스트 이름 및 블록 장치를 포함하여 세부 정보를 나열합니다.

    # ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T '"
    
    nodea
    sdb    8:16   0    1T  0 disk
    Copy to Clipboard Toggle word wrap
  2. ssh 유틸리티를 사용하여 클러스터의 각 VM이 동일한 공유 디스크를 사용하는지 확인합니다.

    # ssh <ip_address> "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='"
    Copy to Clipboard Toggle word wrap

    예를 들어 다음 명령은 인스턴스 IP 주소 198.51.100.3 의 호스트 이름 및 공유 디스크 볼륨 ID를 포함하여 세부 정보를 나열합니다.

    # ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='"
    
    nodea
    E: ID_SERIAL=3600224808dd8eb102f6ffc5822c41d89
    Copy to Clipboard Toggle word wrap

    각 VM이 공유 디스크에 연결되어 있는지 확인한 후 클러스터에 대한 탄력적 스토리지를 구성할 수 있습니다.

5장. Secure Boot를 사용하여 Azure에서 RHEL 구성

UEFI(Unified Extensible Firmware Interface) 사양의 Secure Boot 메커니즘은 부팅 시 프로그램 실행을 제어합니다. Secure Boot는 부팅 시 부트 로더 및 기타 구성 요소의 디지털 서명을 확인하여 인증되지 않은 프로그램을 방지하면서 신뢰할 수 있고 인증된 프로그램만 실행합니다.

Azure 플랫폼에서 공개적으로 사용할 수 있는 RHEL 이미지에는 기본적으로 Secure Boot가 포함되어 있습니다. 허용된 서명 데이터베이스(db)에는 Microsoft 인증서가 있습니다. Azure Compute Cryostat에 새 이미지 버전을 등록하면 UEFI Secure Boot 변수에 사용자 지정 인증서를 추가할 수 있습니다.

5.1. 클라우드에서 RHEL의 Secure Boot 이해

Secure Boot는 UEFI(Unified Extensible Firmware Interface)의 기능입니다. 부팅 로더 및 커널과 같은 신뢰할 수 있고 디지털 서명된 프로그램 및 구성 요소만 부팅 시 실행되도록 합니다. Secure Boot는 하드웨어에 저장된 신뢰할 수 있는 키에 대해 디지털 서명을 확인합니다. 신뢰할 수 없는 엔티티에서 서명한 변조된 구성 요소 또는 구성 요소를 감지하면 부팅 프로세스가 중단됩니다. 이 작업을 수행하면 악성 소프트웨어가 운영 체제를 손상시키는 것을 방지할 수 있습니다.

Secure Boot는 신뢰할 수 있는 엔티티만 부팅 체인에 참여하도록 하여 CVM(Confidential Virtual Machine)을 구성하는 데 중요한 역할을 합니다. 정의된 인터페이스를 통해 특정 장치 경로에 대한 액세스를 인증하고 최신 구성을 사용하고 이전 구성을 영구적으로 덮어씁니다. RHEL(Red Hat Enterprise Linux) 커널이 Secure Boot가 활성화된 상태에서 부팅되면 잠금 모드로 전환되어 신뢰할 수 있는 벤더가 서명한 커널 모듈만 로드할 수 있습니다. 결과적으로 Secure Boot는 운영 체제 부팅 순서의 보안을 강화합니다.

5.1.1. Secure Boot의 구성 요소

Secure Boot 메커니즘은 펌웨어, 서명 데이터베이스, 암호화 키, 부트 로더, 하드웨어 모듈 및 운영 체제로 구성됩니다. 다음은 UEFI 신뢰할 수 있는 변수의 구성 요소입니다.

  • KEK(Key Exchange Key Database): RHEL 운영 체제와 VM 펌웨어 간의 신뢰를 구축하기 위한 공개 키 교환입니다. 이러한 키를 사용하여 허용된 서명 데이터베이스(db) 및 Forbidden 서명 데이터베이스(dbx)를 업데이트할 수도 있습니다.
  • 플랫폼 키 데이터베이스(PK): VM 펌웨어와 클라우드 플랫폼 간의 신뢰를 구축하기 위한 자체 서명된 단일 키 데이터베이스입니다. PK는 KEK 데이터베이스도 업데이트합니다.
  • 허용되는 서명 데이터베이스(db): 바이너리 파일이 시스템에서 부팅할 수 있는지 여부를 확인하기 위해 인증서 또는 바이너리 해시 목록을 유지 관리하는 데이터베이스입니다. 또한 db 의 모든 인증서를 RHEL 커널의 .platform 인증 키로 가져옵니다. 이 기능을 사용하면 서명된 타사 커널 모듈을 잠금 모드에서 추가하고 로드할 수 있습니다.
  • 금지된 서명 데이터베이스(dbx): 시스템에서 부팅할 수 없는 인증서 또는 바이너리 해시 목록을 유지 관리하는 데이터베이스입니다.
참고

바이너리 파일은 dbx 데이터베이스 및 SBAT(Secure Boot Advanced Targeting) 메커니즘에 대해 확인합니다. SBAT를 사용하면 서명된 바이너리가 있는 인증서를 유효한 상태로 유지하여 이전 버전의 특정 바이너리를 취소할 수 있습니다.

5.1.2. 클라우드에서 RHEL용 Secure Boot 단계

RHEL 인스턴스가 NFV(Unified Kernel Image) 모드에서 부팅되고 Secure Boot가 활성화된 상태에서 부팅하면 RHEL 인스턴스가 다음과 같은 순서로 클라우드 서비스 인프라와 상호 작용합니다.

  1. initialization: RHEL 인스턴스가 부팅되면 클라우드 호스팅 펌웨어가 처음에 Secure Boot 메커니즘을 부팅하고 구현합니다.
  2. 변수 저장소 초기화: 펌웨어는 펌웨어가 부팅 프로세스 및 런타임 작업에 대해 관리해야 하는 정보의 전용 스토리지 영역인 변수 저장소의 UEFI 변수를 초기화합니다. RHEL 인스턴스가 처음 부팅되면 저장소는 VM 이미지와 연결된 기본값에서 초기화됩니다.
  3. 부트 로더: 부팅 시 펌웨어가 첫 번째 단계 부트 로더를 로드합니다. x86 UEFI 환경의 RHEL 인스턴스의 경우 첫 번째 단계 부트 로더는 shim입니다. shim 부트 로더는 부팅 프로세스의 다음 단계를 인증 및 로드하고 UEFI와 GRUB 간의 브리지 역할을 합니다.

    1. RHEL의 shim x86 바이너리는 현재 Microsoft Corporation UEFI CA 2011 Microsoft 인증서에서 서명하여 허용된 서명 데이터베이스(db)에 기본 Microsoft 인증서가 있는 다양한 하드웨어 및 가상화된 플랫폼에서 RHEL 인스턴스가 Secure Boot가 활성화된 모드에서 부팅할 수 있도록 합니다.
    2. shim 바이너리는 Red Hat Secure Boot CA 및 필요한 경우MOK(Machine Owner Key)를 사용하여 신뢰할 수 있는 인증서 목록을 확장합니다.
  4. UKI: shim 바이너리가 RHEL UKI( kernel-uki-virt 패키지)를 로드합니다. 해당 인증서인 x86_64 아키텍처의 Red Hat Secure Boot Signing 504 는 UKI에 서명합니다. 이 인증서는 redhat-sb-certs 패키지에서 찾을 수 있습니다. Red Hat Secure Boot CA는 이 인증서에 서명하므로 확인에 성공합니다.
  5. UKI 애드온: UKI cmdline 확장을 사용할 때 RHEL 커널은 shim과 함께 제공되는 db,MOK 및 인증서에 대해 서명을 적극적으로 확인합니다. 이 프로세스를 통해 운영 체제 벤더 RHEL 또는 사용자가 확장 기능에 서명했습니다.

RHEL 커널이 Secure Boot 모드에서 부팅되면 잠금 모드가 됩니다. 잠금을 입력한 RHEL 커널은 db 키를 .platform 인증 키에 추가하고 MOK 키를 .machine 인증 키에 추가합니다. 커널 빌드 프로세스 중에 빌드 시스템은 개인 키와 공개 키로 구성된 임시 키로 작동합니다. 빌드 시스템은 kernel-modules-core, kernel-modules ,kernel- modules -extra와 같은 표준 RHEL 커널 모듈에 서명합니다. 각 커널 빌드가 완료되면 타사 모듈에 서명하기 위해 개인 키가 사용되지 않습니다. 이러한 목적으로 dbMOK 의 인증서를 사용할 수 있습니다.

5.2. Secure Boot를 사용하여 Azure에서 RHEL VM 구성

Azure 클라우드 플랫폼의 RHEL(Red Hat Enterprise Linux) 인스턴스에 보안 운영 체제 부팅 프로세스가 있는지 확인하려면 Secure Boot를 사용합니다. 사용자 지정 RHEL Azure 이미지가 등록되면 이미지는 Secure Boot의 사전 저장된 UEFIFI(Unified Extensible Firmware Interface) 변수로 구성됩니다. 이렇게 하면 RHEL 이미지에서 시작된 모든 인스턴스가 첫 번째 부팅 시 필요한 변수와 함께 Secure Boot 메커니즘을 사용할 수 있습니다.

Microsoft Azure는 신뢰할 수 있는 시작 VM을 사용하여 Secure Boot를 지원합니다. 이러한 VM은 루트킷 및 부트킷으로부터 보호하는 보안 메커니즘을 제공하는 동시에 vTPM(Virtual Trusted Platform Manager)과 같은 추가 기능을 제공합니다. GUI를 사용하여 인스턴스를 만들 때 보안 기능 구성 설정에서 보안 부팅 활성화 옵션을 찾을 수 있습니다.

Azure 플랫폼의 Secure Boot

사전 요구 사항

  • 패키지를 설치했습니다.

    • python3
    • OpenSSL
    • efivar
    • keyutils
    • python3-virt-firmware
  • azure-cli 유틸리티를 설치했습니다. 자세한 내용은 Linux에 Azure CLI 설치를 참조하십시오.

프로세스

  1. openssl 유틸리티를 사용하여 사용자 정의 인증서 custom_db.cer 를 생성합니다.

    $ openssl req -quiet \
    -newkey rsa:4096 \
    -nodes -keyout custom_db.key \
    -new -x509 \
    -sha256 -days 3650 \
    -subj "/CN=Signature Database key/" \
    --outform DER \
    -out custom_db.cer
    Copy to Clipboard Toggle word wrap
  2. 인증서를 base64로 변환 - 인코딩된 형식으로 변환합니다.

    $ echo base64 -w0 custom_db.cer
    
    MIIFIjCCAwqgAwIBAgITNf23J4k0d8c0NR ....
    Copy to Clipboard Toggle word wrap
  3. 새 Azure Compute Cryostat 이미지 버전을 등록하기 위해 azure-example-template.json (ARM) 파일을 생성하고 편집합니다.

    $ vi azure-example-template.json
    
    {
        "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
        "contentVersion": "1.0.0.0",
        "resources": [
            {
                "type": "Microsoft.Compute/galleries/images/versions",
                "apiVersion": "2023-07-03",
                "name": "<your compute gallery/your image definition/version>",
                "location": "<location of the VHD>",
                "properties": {
                    "storageProfile": {
                        "osDiskImage": {
                            "source": {
                                "id": "<your-storage-account-id>",
                                "uri": "<url-with-the-vhd>"
                            },
                            "hostCaching": "ReadOnly"
                        }
                    },
                    "securityProfile": {
                        "uefiSettings": {
                            "signatureTemplateNames": [
                                "MicrosoftUefiCertificateAuthorityTemplate"
                            ],
                            "additionalSignatures": {
                                "db": [
                                    {
                                        "type": "x509",
                                        "value": [
                                            "<base64 of custom_db.cer>"
                                        ]
                                    }
                                ]
                            }
                        }
                    }
                }
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  4. azure-cli 유틸리티를 사용하여 이미지 버전을 등록합니다.

    $ az deployment group create --name <example_deployment> \
    --resource-group <example_resource_group> \
    --template-file <example_template.json>
    Copy to Clipboard Toggle word wrap
  5. Azure 포털에서 인스턴스를 재부팅합니다.

검증

  1. 새로 생성된 RHEL 인스턴스에 Secure Boot가 활성화되어 있는지 확인합니다.

    $ mokutil --sb-state
    SecureBoot enabled
    Copy to Clipboard Toggle word wrap
  2. keyctl 유틸리티를 사용하여 사용자 정의 인증서의 커널 인증 키를 확인합니다.

    $ sudo keyctl list %:.platform
    
    keys in keyring:
    ...
    586621657: ---lswrv   0   0
    asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
    ...
    Copy to Clipboard Toggle word wrap

6장. Intel TDX를 사용하여 퍼블릭 클라우드 플랫폼에서 RHEL 구성

Intel Trust Domain Extensions (TDX)는 VM에 안전하고 격리된 환경을 제공하는 보안 유형의 CVM(Confidential Virtual Machine)입니다. 이 접근 방식은 이전 기술인 Intel Software Guard Extensions (SGX)의 발전입니다.

SGX는 확장이라는 보안 메모리 영역을 생성하여 하이퍼바이저 및 클라우드 서비스 공급자로부터 VM 격리를 제공합니다. enclaves에 저장된 애플리케이션 코드는 enclave 내에 저장된 메모리 및 데이터에 액세스할 수 있으므로 외부 엔티티가 액세스할 수 없습니다.

TDX는 신뢰할 수 있는 도메인(TD)이라는 하드웨어 격리 VM을 생성합니다. VM만 해당 메모리에 액세스하고 TD VM은 VM(Virtual Machine Manager), 하이퍼바이저, 기타 VM 및 호스트와 격리됩니다. 이를 통해 하이퍼바이저, CPU, TD VM의 리소스를 사용하는 동안 데이터 기밀성과 무결성을 유지하여 안전하게 유지됩니다.

SGX와 TDX의 주요 차이점은 SGX가 애플리케이션 수준에서 작동하며 TDX는 하이퍼바이저 액세스를 제한하여 가상화 수준에서 작동한다는 것입니다.

참고

퍼블릭 클라우드 플랫폼에 RHEL(Red Hat Enterprise Linux)을 배포하기 전에 특정 RHEL 인스턴스 유형의 지원 상태 및 인증을 위해 해당 클라우드 서비스 공급자를 확인하십시오.

6.1. Intel TDX 보안 부팅 프로세스 이해

  1. 초기화 및 측정: TDX 지원 하이퍼바이저는 VM의 초기 상태를 설정합니다. 이 하이퍼바이저는 펌웨어 바이너리 파일을 VM 메모리에 로드하고 초기 레지스터 상태를 설정합니다. Intel 프로세서는 VM의 초기 상태를 측정하고 VM의 초기 상태를 확인하는 세부 정보를 제공합니다.
  2. 펌웨어: VM이 UEFI 펌웨어를 시작합니다. 펌웨어에는 상태 저장 또는 상태 비저장 vTPM(Virtual Trusted Platform Module) 구현이 포함될 수 있습니다. 상태 저장 vTPM은 VM 재부팅 및 마이그레이션 전반에 걸쳐 지속적인 암호화 상태를 유지하지만 상태 비저장 vTPM은 지속성 없이 각 VM 세션에 대해 새로운 암호화 상태를 생성합니다. VMI(가상 머신 권한 수준) 기술은 게스트에서 vTPM을 격리합니다. VMPL은 서로 다른 VM 구성 요소와 하이퍼바이저 간에 하드웨어 적용 권한 격리를 제공합니다.
  3. VTPM : 클라우드 서비스 공급자에 따라 상태 저장 vTPM 구현을 위해 UEFI 펌웨어가 vTPM의 영구 상태를 해독하기 위해 원격 인증을 수행할 수 있습니다. 또한 vTPM은 Secure Boot 상태, 부팅 아티팩트 서명에 사용되는 인증서 또는 UEFI 바이너리 해시와 같은 부팅 프로세스에 대한 데이터를 수집합니다.
  4. shim : UEFI 펌웨어가 초기화 프로세스를 완료하면 확장 펌웨어 인터페이스 (EFI) 시스템 파티션을 검색합니다. 그런 다음 UEFI 펌웨어가 첫 번째 단계 부트 로더를 확인하고 실행합니다. RHEL의 경우 shim 입니다. shim 프로그램을 사용하면 Microsoft 이외의 운영 체제가 EFI 시스템 파티션에서 두 번째 단계 부트 로더를 로드할 수 있습니다.

    1. shim 은 Red Hat 인증서를 사용하여 두 번째 단계 부트 로더(grub) 또는 Red Hat Unified Kernel Image(UKI)를 확인합니다.
    2. GRUB 또는 UKI 의 압축을 풀고, 검증하고, Linux 커널 및 initramfs와 커널 명령줄을 실행합니다. 이 프로세스를 통해 Linux 커널이 신뢰할 수 있고 보안된 환경에 로드됩니다.
  5. initramfs : initramfs에서 vTPM 정보는 전체 디스크 암호화 기술의 경우 암호화된 루트 파티션의 잠금을 자동으로 해제합니다.

    1. 루트 볼륨을 사용할 수 있게 되면 initramfs 에서 실행 흐름을 전송합니다.
  6. 인증: VM 테넌트는 시스템에 액세스할 수 있으며 원격 인증을 수행하여 액세스되지 않은 VM이 CVM(Contampered Confidential Virtual Machine)인지 확인할 수 있습니다. 인증 정보는 Intel 프로세서 및 vTPM의 정보를 기반으로 수행됩니다. 이 프로세스는 RHEL 인스턴스 및 Intel 프로세서의 초기 CPU 및 메모리 상태의 신뢰성과 신뢰성을 확인합니다.
  7. TEE: 이 프로세스에서는 신뢰할 수 있는 실행 환경(TEE)을 생성하여 VM 부팅이 신뢰할 수 있고 보안된 환경에 있는지 확인합니다.

6.2. Intel TDX를 사용하여 Azure에서 RHEL VM 구성

Intel Trusted Domain Extensions (TDX)를 사용하면 신뢰할 수 있는 도메인(TD)이라는 하드웨어 기반 격리된 VM을 만들 수 있습니다. 하이퍼바이저 및 호스트에 액세스할 수 있는 상태에서 VM만 해당 리소스에 액세스할 수 있도록 합니다.

사전 요구 사항

  • opensshopenssh-clients 패키지를 설치했습니다.
  • Azure CLI 유틸리티를 설치했습니다. 자세한 내용은 Linux에 Azure CLI 설치를 참조하십시오.
  • 지원되는 Azure 인스턴스 유형에서 RHEL 인스턴스를 시작했습니다. 자세한 내용은 Azure Confidential VM 옵션을 참조하십시오.

프로세스

  1. azure cli 유틸리티를 사용하여 Azure에 로그인합니다.

    $ az login
    Copy to Clipboard Toggle word wrap
  2. 선택한 가용성 영역에 대한 Azure 리소스 그룹을 생성합니다.

    $ az group create --name <example_resource_group> --location westeurope
    Copy to Clipboard Toggle word wrap
  3. TDX가 활성화된 RHEL 인스턴스를 배포합니다(예: Standard_DC2eds_v5 인스턴스 유형).

    $ az vm create --resource-group <example_resource_group> \
    --name <example_rhel_instance> \
    --image <"RedHat:rhel-cvm:9_5_cvm:latest"> \
    --size <Standard_DC2eds_v5> \
    --admin-username <example_azure_user> \
    --generate-ssh-keys \
    --security-type ConfidentialVM \
    --os-disk-security-encryption-type DiskWithVMGuestState
    Copy to Clipboard Toggle word wrap
  4. RHEL 인스턴스에 연결합니다.

    $ ssh <example_azure_user>@<example_ip_address_of_the_instance>
    Copy to Clipboard Toggle word wrap

검증

  • 커널 로그를 확인하여 TDX의 상태를 확인합니다.

    $ sudo dmesg | grep -i tdx
    Copy to Clipboard Toggle word wrap
    ...
    [    0.733613] Memory Encryption Features active: Intel TDX
    [    4.320222] systemd[1]: Detected confidential virtualization tdx.
    [    5.977432] systemd[1]: Detected confidential virtualization tdx.
    ...
    Copy to Clipboard Toggle word wrap
  • RHEL 인스턴스 구성의 메타데이터를 확인합니다.

    $ az vm show --resource-group <example_resource_group> \
    --name <example_rhel_instance> \
    --query "securityProfile.enableTrustedDomainExtensions" \
    --output json
    Copy to Clipboard Toggle word wrap

7장. AMD SEV SNP를 사용하여 퍼블릭 클라우드 플랫폼에서 RHEL 구성

Secure Nested Paging(SEV-SNP)이 포함된 AMD Secure Encrypted Virtualization은 VM 무결성 기반 공격을 방지하고 메모리 무결성 위반의 위험을 줄이는 것을 목표로 합니다. 보안 부팅 프로세스의 경우 AMD 프로세서는 세 가지 하드웨어 기반 보안 메커니즘, SEV(Secure Encrypted Virtualization), SEV 암호화 상태(SEV-ES) 및 SEV Secure Nested Paging(SEV-SNP)을 제공합니다.

  • SEV: SEV 메커니즘은 하이퍼바이저가 VM 데이터에 액세스하지 못하도록 VM(가상 머신) 메모리를 암호화합니다.
  • SEV-ES: 암호화 상태(SEV-ES)가 있는 SEV는 CPU 레지스터 상태를 암호화하여 SEV를 확장합니다. 이 메커니즘은 하이퍼바이저가 VM CPU 레지스터에 액세스하거나 수정하지 못하도록 합니다. 하이퍼바이저와 VM 간에 격리를 제공했음에도 불구하고 메모리 무결성 공격에 여전히 취약합니다.
  • SEV-SNP: SEV-SNP는 VM 암호화와 함께 메모리 무결성 보호를 추가하는 SEV-ES의 개선 사항입니다. 이 메커니즘은 하이퍼바이저가 페이지 테이블을 수정하여 VM 메모리 액세스를 리디렉션하지 못하도록 하여 재생 공격 및 메모리 변조를 방지합니다.

    참고

    퍼블릭 클라우드 플랫폼에 RHEL(Red Hat Enterprise Linux)을 배포하기 전에 특정 RHEL 인스턴스 유형의 지원 상태 및 인증을 위해 해당 클라우드 서비스 공급자를 확인하십시오.

7.1. SEV-SNP 속성

  • Secure Processor: AMD EPYC 프로세서는 SP(Secure Processor) 하위 시스템을 통합합니다. AMD SP는 키 및 암호화 작업을 관리하기 위한 전용 하드웨어 구성 요소입니다.
  • 메모리 무결성: 가상화 및 격리를 관리하기 위해 MMU(메모리 관리 단위)는 페이지 테이블을 사용하여 가상 주소를 게스트 물리적 주소로 변환합니다. SEV-SNP는 게스트 물리 주소를 호스트 물리적 주소로 변환하는 데 중첩된 페이지 테이블을 사용합니다. 중첩된 페이지 테이블이 정의되면 하이퍼바이저 또는 호스트에서 페이지 테이블을 변경하여 VM을 다른 페이지에 액세스하도록 수정하여 메모리 무결성을 보호할 수 없습니다. SEV-SNP는 이 방법을 사용하여 재생 공격 및 VM 메모리에 대한 악의적인 수정에 대한 보호를 제공합니다.
  • 메모리 암호화: AMD EPYC 프로세서는 호스트와 VM 모두에서 숨겨진 메모리 암호화 키를 숨깁니다.
  • 확인을 위한 인증 보고서: 인증된 암호화 형식의 RHEL 인스턴스 정보에 대한 CPU 생성 보고서입니다. 이 프로세스는 RHEL 인스턴스 및 AMD 프로세서의 초기 CPU 및 메모리 상태의 신뢰성과 신뢰성을 확인합니다.

    참고

    하이퍼바이저가 VM의 기본 메모리 및 CPU 레지스터 상태를 생성하는 경우에도 해당 VM을 초기화한 후 숨겨지고 하이퍼바이저에 액세스할 수 없습니다.

7.2. AMD SEV SNP 보안 부팅 프로세스 이해

  1. 초기화 및 측정: SEV-SNP가 활성화된 하이퍼바이저는 VM의 초기 상태를 설정합니다. 이 하이퍼바이저는 펌웨어 바이너리를 VM 메모리에 로드하고 초기 레지스터 상태를 설정합니다. AMD SP(Secure Processor)는 VM의 초기 상태를 측정하고 VM의 초기 상태를 확인하는 세부 정보를 제공합니다.
  2. 펌웨어: VM이 UEFI 펌웨어를 시작합니다. 펌웨어에는 stateful 또는 stateless Virtual Trusted Platform Module (vTPM) 구현이 포함될 수 있습니다. 상태 저장 vTPM은 VM 재부팅 및 마이그레이션 전반에 걸쳐 지속적인 암호화 상태를 유지하지만 상태 비저장 vTPM은 지속성 없이 각 VM 세션에 대해 새로운 암호화 상태를 생성합니다. VMI(가상 머신 권한 수준) 기술은 게스트에서 vTPM을 격리합니다. VMPL은 서로 다른 VM 구성 요소와 하이퍼바이저 간에 하드웨어 적용 권한 격리를 제공합니다.
  3. VTPM : 클라우드 서비스 공급자에 따라 상태 저장 vTPM 구현을 위해 UEFI 펌웨어가 vTPM의 영구 상태를 해독하기 위해 원격 인증을 수행할 수 있습니다.

    1. 또한 vTPM은 Secure Boot 상태, 부팅 아티팩트 서명에 사용되는 인증서, UEFI 바이너리 해시 등과 같은 부팅 프로세스에 대한 사실을 측정합니다.
  4. shim: UEFI 펌웨어가 초기화 프로세스를 완료하면 확장 펌웨어 인터페이스 (EFI) 시스템 파티션을 검색합니다. 그런 다음 UEFI 펌웨어가 첫 번째 단계 부트 로더를 확인하고 실행합니다. RHEL의 경우 shim 입니다. shim 프로그램을 사용하면 Microsoft 이외의 운영 체제가 EFI 시스템 파티션에서 두 번째 단계 부트 로더를 로드할 수 있습니다.

    1. shim 은 Red Hat 인증서를 사용하여 두 번째 단계 부트 로더(grub) 또는 Red Hat Unified Kernel Image(UKI)를 확인합니다.
    2. GRUB 또는 UKI 는 Linux 커널 및 초기 RAM 파일 시스템(initramfs) 및 커널 명령줄의 압축을 풀고 검증 및 실행합니다. 이 프로세스를 통해 Linux 커널이 신뢰할 수 있고 보안된 환경에 로드됩니다.
  5. initramfs : initramfs 에서 vTPM 정보는 전체 디스크 암호화 기술의 경우 암호화된 루트 파티션의 잠금을 자동으로 해제합니다.

    1. 루트 볼륨을 사용할 수 있게 되면 initramfs 에서 실행 흐름을 root 볼륨으로 전송합니다.
  6. 인증: VM 테넌트는 시스템에 액세스할 수 있으며 원격 인증을 수행하여 액세스되지 않은 VM이 CVM(Contampered Confidential Virtual Machine)인지 확인할 수 있습니다. 인증 정보는 AMD SP 및 vTPM의 정보를 기반으로 수행됩니다. 이 프로세스는 RHEL 인스턴스 및 AMD 프로세서의 초기 CPU 및 메모리 상태의 신뢰성과 신뢰성을 확인합니다.
  7. TEE: 이 프로세스에서는 신뢰할 수 있는 실행 환경(TEE)을 생성하여 VM 부팅이 신뢰할 수 있고 보안된 환경에 있는지 확인합니다.

7.3. AMD SEV SNP를 사용하여 Azure에서 RHEL VM 구성

Secure Nested Paging(SEV-SNP)이 포함된 AMD Secure Encrypted Virtualization은 Azure VM(Red Hat Enterprise Linux)의 RHEL(Red Hat Enterprise Linux)에 대한 기밀성 가상 머신(CVM)에 대한 보안 유형이며 AMD EPYC 프로세서 제품군에서만 사용할 수 있습니다. SEV-SNP는 전체 프로세스가 보호되고 보호되므로 하이퍼바이저 및 클라우드 서비스 공급자가 데이터에 액세스할 수 없도록 신뢰할 수 있는 부팅 환경을 제공합니다.

사전 요구 사항

프로세스

  1. Azure CLI 유틸리티를 사용하여 Azure에 로그인합니다.

    $ az login
    Copy to Clipboard Toggle word wrap
  2. 선택한 가용성 영역에 대한 azure 리소스 그룹을 생성합니다.

    $ az group create --name <example_resource_group> --location eastus
    Copy to Clipboard Toggle word wrap
  3. SEV-SNP를 사용하여 RHEL 인스턴스를 배포합니다. 예를 들면 Standard_DC4as_V5 인스턴스 유형입니다.

    $ az vm create --resource-group <example_resource_group> \
    --name <example-rhel-10-sev-snp-instance> \
    --image <RedHat:rhel:10_x64_Gen2:latest> \
    --size <Standard_DC4as_V5> \
    --admin-username <example_azure_user> \
    --generate-ssh-keys \
    --security-type ConfidentialVM \
    --os-disk-security-encryption-type DiskWithVMGuestState
    Copy to Clipboard Toggle word wrap
  4. RHEL 인스턴스에 연결합니다.

    $ ssh <example_azure_user>@<example_ip_address_of_VM>
    Copy to Clipboard Toggle word wrap

검증

  • 커널 로그를 확인하여 SEV-SNP 상태를 확인합니다.

    $ sudo dmesg | grep -i sev
    Copy to Clipboard Toggle word wrap
    ...
    [    0.547223] Memory Encryption Features active: AMD SEV
    [    4.843171] kvm-guest: setup_efi_kvm_sev_migration : EFI live migration variable not found
    ...
    Copy to Clipboard Toggle word wrap

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat
맨 위로 이동