Google Cloud Platform에서 RHEL 배포 및 관리


Red Hat Enterprise Linux 10

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

Red Hat Customer Content Services

초록

퍼블릭 클라우드 환경에서 RHEL(Red Hat Enterprise Linux)을 사용하려면 GCP(Google Cloud Platform)를 비롯한 다양한 클라우드 플랫폼에 RHEL 시스템 이미지를 생성하고 배포할 수 있습니다. GCP에서 HA(Red Hat High Availability) 클러스터를 생성하고 구성할 수도 있습니다. 다음 장에서는 GCP에서 클라우드 RHEL 인스턴스 및 HA 클러스터를 생성하는 방법을 설명합니다. 이러한 프로세스에는 필수 패키지 및 에이전트 설치, 펜싱 구성, 네트워크 리소스 에이전트 설치가 포함됩니다.

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 게스트 운영 체제는 가상화된 커널에서 실행됩니다. 이 커널은 호스트 운영 체제와 인스턴스에 연결하는 데 사용하는 클라이언트 시스템과 다릅니다.

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

    또한 인스턴스의 운영 체제가 불안정해지거나 손상되는 경우에도 클라이언트 시스템은 어떤 방식으로든 영향을 받지 않습니다.

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

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

유용한 사용 사례

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

    • 최대 워크로드 및 낮은 일반 성능 요구 사항이 있는 클러스터입니다. 필요에 따라 확장 및 축소하면 리소스 비용 측면에서 매우 효율적일 수 있습니다.
    • 클러스터를 신속하게 설정하거나 확장합니다. 이렇게 하면 로컬 서버를 설정하는 데 드는 초기 비용이 발생하지 않습니다.
  • 클라우드 인스턴스는 로컬 환경에서 발생하는 작업의 영향을 받지 않습니다. 따라서 백업 및 재해 복구에 사용할 수 있습니다.

잠재적으로 문제가 있는 사용 사례

  • 조정할 수 없는 기존 환경을 실행하고 있습니다. 기존 배포의 특정 요구에 맞게 클라우드 인스턴스를 사용자 정의하는 것은 현재 호스트 플랫폼과 비교하여 비용 효율적이지 않을 수 있습니다.
  • 예산에 하드 제한으로 작업하고 있습니다. 로컬 데이터 센터에서 배포를 유지 관리하면 일반적으로 퍼블릭 클라우드보다 유연성이 떨어지지만 최대 리소스 비용을 제어할 수 있습니다.

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

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

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

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

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

내 데이터가 로컬 서버와 달리 퍼블릭 클라우드에서 안전하게 유지됩니까?

RHEL 클라우드 인스턴스의 데이터는 소유권에 있으며 퍼블릭 클라우드 공급자는 이에 액세스할 수 없습니다.

또한 주요 클라우드 공급자는 전송 시 데이터 암호화를 지원하므로 가상 머신을 퍼블릭 클라우드로 마이그레이션할 때 데이터의 보안이 향상됩니다.

RHEL 퍼블릭 클라우드 인스턴스의 일반 보안은 다음과 같이 관리됩니다.

  • 클라우드 하이퍼바이저의 보안을 담당하는 퍼블릭 클라우드 공급자
  • Red Hat은 인스턴스의 RHEL 게스트 운영 체제의 보안 기능을 제공합니다.
  • 클라우드 인프라의 특정 보안 설정 및 관행을 관리합니다.

내 지역이 RHEL 퍼블릭 클라우드 인스턴스의 기능에 미치는 영향은 무엇입니까?

지리적 위치에 관계없이 퍼블릭 클라우드 플랫폼에서 RHEL 인스턴스를 사용할 수 있습니다. 따라서 온-프레미스 서버와 동일한 리전의 인스턴스를 실행할 수 있습니다.

그러나 물리적으로 멀리 있는 지역에 인스턴스를 호스트하면 작동 시 대기 시간이 길어질 수 있습니다. 또한 퍼블릭 클라우드 공급자에 따라 특정 리전에서 추가 기능을 제공하거나 비용 효율성을 높일 수 있습니다. RHEL 인스턴스를 만들기 전에 선택한 클라우드 공급자에 사용할 수 있는 호스팅 리전의 속성을 검토하십시오.

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

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

  1. 요구 사항과 현재 출시에 따라 사용 사례에 맞는 최적의 클라우드 공급자를 선택합니다.

    RHEL 인스턴스를 실행하는 데 필요한 인증된 클라우드 서비스 공급자(CCSP)는 다음과 같습니다.

  2. 선택한 클라우드 플랫폼에 RHEL 클라우드 인스턴스를 생성합니다. 자세한 내용은 RHEL 클라우드 인스턴스 생성 방법을 참조하십시오.
  3. RHEL 배포를 최신 상태로 유지하려면 RHUI( Red Hat Update Infrastructure )를 사용하십시오.

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

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

RHEL 시스템 이미지를 생성하여 클라우드 플랫폼으로 가져옵니다.

  • 시스템 이미지를 생성하려면 RHEL 이미지 빌더를 사용하거나 이미지를 수동으로 빌드할 수 있습니다.
  • 이 방법은 기존 RHEL 서브스크립션을 사용하며 BYOOS(사용자 서브스크립션 )라고도 합니다.
  • 연간 서브스크립션 비용을 미리 지불하면 Red Hat 고객 할인 혜택을 누릴 수 있습니다.
  • 고객의 고객 서비스는 Red Hat에서 제공합니다.
  • 효과적으로 여러 이미지를 생성하기 위해 cloud-init 툴을 사용할 수 있습니다.

클라우드 공급자 마켓플레이스에서 직접 RHEL 인스턴스를 구입

  • 서비스 사용에 대한 시간당 요금을 지불하십시오. 따라서,이 방법은 또한 지불 (PAYG)이라고합니다.
  • 고객 서비스는 클라우드 플랫폼 공급자가 제공합니다.
참고

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

2장. 사용자 정의 GCE 이미지 준비 및 GCP에 업로드

RHEL 이미지 빌더를 사용하면 gce 이미지를 빌드하고 사용자 또는 GCP 서비스 계정에 대한 인증 정보를 제공한 다음 gce 이미지를 GCP 환경에 직접 업로드할 수 있습니다.

2.1. CLI를 사용하여 GCP에 gce 이미지 구성 및 업로드

RHEL 이미지 빌더 CLI를 사용하여 gce 이미지를 GCP에 업로드하도록 인증 정보가 포함된 구성 파일을 설정합니다.

주의

이미지가 부팅되지 않으므로 gce 이미지를 GCP에 수동으로 가져올 수 없습니다. gcloud 또는 RHEL 이미지 빌더를 사용하여 업로드해야 합니다.

사전 요구 사항

  • 이미지를 GCP에 업로드할 수 있는 유효한 Google 계정 및 인증 정보가 있습니다. 자격 증명은 사용자 계정 또는 서비스 계정에서 있을 수 있습니다. 인증 정보와 연결된 계정에는 최소한 다음 IAM 역할이 할당되어 있어야 합니다.

    • roles/storage.admin - 스토리지 오브젝트 생성 및 삭제
    • roles/compute.storageAdmin - VM 이미지를 Compute Engine으로 가져옵니다.
  • 기존 GCP 버킷이 있습니다.

프로세스

  1. 텍스트 편집기를 사용하여 다음 내용으로 gcp-config.toml 구성 파일을 생성합니다.

    provider = "gcp"
    [settings]
    bucket = "GCP_BUCKET"
    region = "GCP_STORAGE_REGION"
    object = "OBJECT_KEY"
    credentials = "GCP_CREDENTIALS"
    Copy to Clipboard
    • GCP_BUCKET 은 기존 버킷을 가리킵니다. 업로드 중인 이미지의 중간 스토리지 오브젝트를 저장하는 데 사용됩니다.
    • GCP_STORAGE_REGION 은 일반 Google 스토리지 영역과 이중 또는 멀티 영역입니다.
    • OBJECT_KEY 는 중간 스토리지 오브젝트의 이름입니다. 업로드 전에는 존재하지 않아야 하며 업로드 프로세스가 완료되면 삭제됩니다. 오브젝트 이름이 .tar.gz 로 끝나지 않으면 확장이 오브젝트 이름에 자동으로 추가됩니다.
    • GCP_CREDENTIALS 는 GCP에서 다운로드한 인증 정보 JSON 파일의 Base64인코딩 체계입니다. 인증 정보에 따라 GCP에서 이미지를 업로드할 프로젝트가 결정됩니다.

      참고

      GCP로 인증하는 다른 메커니즘을 사용하는 경우 gcp-config.toml 파일에 GCP_CREDENTIALS 를 지정하는 것은 선택 사항입니다. 기타 인증 방법은 GCP로 인증 을 참조하십시오.

  2. GCP에서 다운로드한 JSON 파일에서 GCP_CREDENTIALS 를 검색합니다.

    $ sudo base64 -w 0 cee-gcp-nasa-476a1fa485b7.json
    Copy to Clipboard
  3. 추가 이미지 이름 및 클라우드 공급자 프로필을 사용하여 작성을 생성합니다.

    $ sudo composer-cli compose start BLUEPRINT-NAME gce IMAGE_KEY gcp-config.toml
    Copy to Clipboard

    이미지 빌드, 업로드 및 클라우드 등록 프로세스를 완료하는 데 최대 10분이 걸릴 수 있습니다.

검증

  • 이미지 상태가 FINISHED인지 확인합니다.

    $ sudo composer-cli compose status
    Copy to Clipboard

2.2. RHEL 이미지 빌더가 다른 GCP 인증 정보의 인증 순서를 정렬하는 방법

RHEL 이미지 빌더에서 여러 다른 유형의 인증 정보를 사용하여 GCP로 인증할 수 있습니다. RHEL 이미지 빌더 구성이 여러 인증 정보 세트를 사용하여 GCP에서 인증하도록 설정된 경우 다음과 같은 기본 설정 순서대로 인증 정보를 사용합니다.

  1. 구성 파일에서 composer-cli 명령으로 지정된 인증 정보입니다.
  2. osbuild-composer 작업자 구성에 구성된 인증 정보입니다.
  3. 다음 옵션을 사용하여 자동으로 인증할 수 있는 Google GCP SDK 라이브러리의 Application Default Credentials (애플리케이션 기본 인증 정보)입니다.

    1. GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 설정된 경우 애플리케이션 기본 자격 증명은 변수가 가리키는 파일에서 인증 정보를 로드하고 사용합니다.
    2. 애플리케이션 기본 인증 정보는 코드를 실행하는 리소스에 연결된 서비스 계정을 사용하여 인증을 시도합니다. 예를 들면 Google Compute Engine VM입니다.

      참고

      GCP 인증 정보를 사용하여 이미지를 업로드할 GCP 프로젝트를 결정해야 합니다. 따라서 모든 이미지를 동일한 GCP 프로젝트에 업로드하지 않으려면 composer-cli 명령을 사용하여 gcp-config.toml 구성 파일에 인증 정보를 지정해야 합니다.

2.3. composer-cli 명령을 사용하여 GCP 인증 정보 지정

모든 이미지 빌드에 전역적으로 GCP에 사용하도록 GCP 인증 인증 정보를 구성할 수 있습니다. 이렇게 하면 이미지를 동일한 GCP 프로젝트로 가져오려면 GCP에 모든 이미지 업로드에 동일한 인증 정보를 사용할 수 있습니다.

프로세스

  • /etc/osbuild-worker/osbuild-worker.toml 작업자 구성에서 다음 인증 정보 값을 설정합니다.

    [gcp]
    credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"
    Copy to Clipboard

2.4. osbuild-composer 작업자 구성에서 인증 정보 지정

모든 이미지 빌드에 전역적으로 GCP에 사용하도록 GCP 인증 인증 정보를 구성할 수 있습니다. 이렇게 하면 이미지를 동일한 GCP 프로젝트로 가져오려면 GCP에 모든 이미지 업로드에 동일한 인증 정보를 사용할 수 있습니다.

프로세스

  • /etc/osbuild-worker/osbuild-worker.toml 작업자 구성에서 다음 인증 정보 값을 설정합니다.

    [gcp]
    credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"
    Copy to Clipboard

3장. GCP에서 RHEL 이미지를 Google Compute Engine 인스턴스로 배포

GCP(Google Cloud Platform)에서 RHEL 이미지를 사용하려면 이미지를 GCP 호환 형식으로 변환하고 이미지에서 VM을 배포하여 Google Compute Engine(GCE) VM으로 실행합니다. GCE 지원 형식에 RHEL 이미지를 생성, 사용자 정의 및 배포하려면 다음 방법 중 하나를 사용할 수 있습니다.

참고

GCP용 Red Hat 제품 인증 목록은 Google Cloud Platform의 Red Hat을 참조하십시오.

사전 요구 사항

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

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

참고

사용자 지정 ISO 이미지를 배포하려면 Red Hat Image Builder를 사용할 수 있습니다. 이미지 빌더를 사용하면 선택한 CCSP 고유의 사용자 정의 이미지를 생성, 업로드 및 배포할 수 있습니다.

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

Red Hat Image 배포

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

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

CCSP에서 Red Hat Image를 선택합니다. 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 인스턴스 배포

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

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

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

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

참고

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

  • SSH - VM에 대한 원격 액세스를 제공하려면 ssh를 활성화해야 합니다.
  • DHCP - 기본 가상 어댑터는 dhcp에 대해 구성해야 합니다.

사전 요구 사항

  • 호스트 시스템에서 가상화를 활성화했습니다.
  • 웹 콘솔의 경우 다음 옵션을 확인하십시오.

    • Immediately Start VM 옵션을 선택하지 않았습니다.
    • 메모리 크기를 원하는 설정으로 이미 변경했습니다.
    • 가상 네트워크 인터페이스 설정에서 모델 옵션을 virtio 로 변경하고 vCPU 를 VM의 용량 설정으로 변경했습니다.

프로세스

  1. 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 --auto-attach
    Copy to Clipboard

검증

  • cloud-init 패키지가 설치되어 활성화되어 있는지 확인합니다.

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

3.3. GCP에서 RHEL 인스턴스 업로드 및 실행

GCP(Google Cloud Platform)에서 RHEL 인스턴스를 실행하려면 RHEL 이미지를 GCP에 구성하고 업로드해야 합니다.

3.3.1. Google Cloud SDK 설치

Google Cloud SDK를 사용하여 Google Cloud CLI를 사용하여 명령줄에서 Google Cloud Platform(GCP) 리소스 및 서비스를 관리할 수 있습니다.

사전 요구 사항

프로세스

  1. gcloud CLI 유틸리티를 사용하여 프로젝트 및 인스턴스를 관리합니다.
  2. 프로젝트를 생성합니다.

    # gcloud projects create <example-gcp-project-id> --name <example-gcp-project>
    Copy to Clipboard

    이 예제에서는 프로젝트 ID <example-gcp-project-id> 와 프로젝트 이름이 <example-gcp-project> 있는 프로젝트를 생성합니다.

  3. 프로젝트 정보를 표시합니다.

    # gcloud compute <example-project-info> describe --project <example-project-name>
    Copy to Clipboard

3.3.2. GCP에서 새 프로젝트 생성

RHEL 이미지를 GCP(Google Cloud Platform)에 업로드하려면 GCP에서 새 프로젝트를 생성해야 합니다. 프로젝트에서 할당된 Google Cloud 리소스를 관리합니다.

사전 요구 사항

프로세스

  1. GCP 콘솔 을 시작합니다.
  2. Google Cloud Platform 오른쪽에 있는 드롭다운 메뉴를 클릭합니다.
  3. 팝업 메뉴에서 새 프로젝트 를 클릭합니다.
  4. 새 프로젝트 창에서 새 프로젝트의 이름을 입력합니다.
  5. 조직을 확인합니다. 필요한 경우 드롭다운 메뉴를 클릭하여 조직을 변경합니다.
  6. 상위 조직 또는 폴더의 위치를 확인합니다. 필요한 경우 찾아보기 를 클릭하여 이 값을 검색하고 변경합니다.
  7. 만들기 클릭하여 새 GCP 프로젝트를 생성합니다.

3.3.3. Google Cloud Storage에서 RHEL 이미지 생성 및 업로드

VM 이미지와 같은 오브젝트를 가져오고 저장할 GCP 스토리지 버킷을 생성합니다.

프로세스

  1. Google 클라우드 콘솔에 로그인합니다.

    # gcloud auth login
    Copy to Clipboard
  2. 스토리지 버킷을 생성합니다.

    # gsutil mb gs://<example-bucket-name>
    Copy to Clipboard
    참고

    또는 Google Cloud Console을 사용하여 버킷을 생성할 수도 있습니다. 자세한 내용은 버킷 만들기를 참조하십시오.

  3. 생성할 이미지 이름, 기존 버킷 이름 및 이미지 이름을 지정합니다.

    # **gcloud compute images create my-image-name --source-uri gs://__<example-bucket-name>__/disk.raw.tar.gz**
    Copy to Clipboard
    참고

    또는 Google Cloud Console을 사용하여 이미지를 만들 수도 있습니다. 자세한 내용은 사용자 정의 이미지 생성, 삭제 및 사용 중단을 참조하십시오.

  4. 선택 사항: GCP 콘솔에서 이미지를 찾습니다.

    1. Google Cloud Console 배너의 왼쪽에 있는 탐색 메뉴를 클릭합니다.
    2. Compute Engine 을 선택한 다음 이미지를 선택합니다.
  5. qemu-img 명령을 실행하여 qcow2 이미지를 원시 형식으로 변환합니다.

    # qemu-img convert -f qcow2 -O raw rhel-10.0-sample.qcow2 disk.raw
    Copy to Clipboard
  6. 이미지를 압축합니다.

    # tar --format=oldgnu -Sczf disk.raw.tar.gz disk.raw
    Copy to Clipboard
  7. 기존 버킷에 이미지를 업로드합니다.

    # gsutil cp disk.raw.tar.gz gs://<example-bucket-name>
    Copy to Clipboard
    참고

    업로드에 몇 분이 걸릴 수 있습니다.

  8. Google Cloud Platform 홈 화면에서 축소된 메뉴 아이콘을 클릭하고 스토리지를 선택한 다음 브라우저를 선택합니다.
  9. disk.raw.tar.gz 가 나열된 버킷 이름을 클릭합니다.

    참고

    GCP 콘솔을 사용하여 이미지를 업로드할 수도 있습니다. 이렇게 하려면 버킷 이름을 클릭한 다음 파일 업로드 를 클릭합니다.

3.3.4. RHEL Google Compute Engine 인스턴스 시작 및 연결

이미지에서 GCE VM 인스턴스를 구성하려면 GCP 콘솔을 사용합니다.

프로세스

  1. GCP 콘솔 대시보드 페이지에서 Google Cloud Console 배너 의 왼쪽에 있는 탐색 메뉴를 클릭하고 Compute Engine 을 선택한 다음 이미지를 선택합니다.
  2. 이미지를 선택합니다.
  3. 인스턴스 생성을 클릭합니다.
  4. 인스턴스 만들기 페이지에서 인스턴스이름을 입력합니다.
  5. 지역영역을 선택합니다.
  6. 워크로드 요구 사항을 충족하거나 초과하는 머신 구성 을 선택합니다.
  7. 부팅 디스크가 이미지 이름을 지정했는지 확인합니다.
  8. 선택 사항: 방화벽 아래에서 HTTP 트래픽 허용 또는 HTTPS 트래픽 허용 을 선택합니다.
  9. 생성을 클릭합니다.
  10. VM 인스턴스에서 이미지를 찾습니다.
  11. Google Cloud Console 배너 왼쪽에 있는 탐색 메뉴를 클릭하고 Compute Engine 을 선택한 다음 VM 인스턴스를 선택합니다.

    참고

    또는 gcloud compute instances create 명령을 사용하여 이미지에서 GCE VM 인스턴스를 생성할 수 있습니다.

    # gcloud compute instances create myinstance3 --zone=us-central1-a --image test-iso2-image
    Copy to Clipboard

    이 예제에서는 기존 이미지 test-iso2-image 를 기반으로 영역 us-central1-amyinstance3 이라는 VM 인스턴스를 생성합니다. 자세한 내용은 gcloud 컴퓨팅 인스턴스 생성을 참조하십시오.

  12. ssh-keygen 유틸리티를 사용하여 공용 IP 주소를 사용하여 GCE와 함께 사용할 SSH 키 쌍을 생성합니다.

    # ssh-keygen -t rsa -f ~/.ssh/google_compute_engine.pub
    Copy to Clipboard
  13. GCP 콘솔 대시보드 페이지에서 Google Cloud Console 배너 의 왼쪽에 있는 탐색 메뉴를 클릭하고 Compute Engine 을 선택한 다음 Metadata 를 선택합니다.
  14. SSH 키를 클릭한 다음 편집 을 클릭합니다.
  15. ~/.ssh/google_compute_engine.pub 파일에서 생성된 출력을 입력하고 저장을 클릭합니다.
  16. 인스턴스에 연결합니다.

    # ssh -i ~/.ssh/google_compute_engine <username>@<instance_external_ip>
    Copy to Clipboard
    참고

    또는 gcloud compute config-ssh 명령을 실행하여 구성 파일을 인스턴스의 별칭으로 채울 수 있습니다. 별칭을 사용하면 인스턴스 이름별로 간단한 SSH 연결을 수행할 수 있습니다. 자세한 내용은 gcloud compute config-ssh 를 참조하십시오.

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

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

사전 요구 사항

프로세스

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

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

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

    # insights-client register --display-name <display-name-value>
    Copy to Clipboard

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

4장. GCP에서 Red Hat High Availability Cluster 구성

HA(고가용성) 클러스터 솔루션을 사용하면 RHEL 노드 클러스터를 생성하여 노드 장애가 발생하면 자동으로 워크로드를 재배포할 수 있습니다. 이러한 HA 클러스터는 GCP(Google Cloud Platform)와 같은 퍼블릭 클라우드 플랫폼에도 배포할 수 있습니다. GCP에서 HA 클러스터를 설정하는 것은 클라우드 이외의 환경에서 구성하는 것과 유사합니다.

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

사전 요구 사항

프로젝트 관리자가 사용자 지정 서비스 계정을 생성하는 경우 다음 역할에 대해 서비스 계정을 구성해야 합니다.

  • 클라우드 추적 에이전트
  • 컴퓨팅 관리자
  • 컴퓨팅 네트워크 관리자
  • Cloud Datastore 사용자
  • 로깅 관리자
  • 모니터링 편집기
  • 모니터링 지표 작성기
  • 서비스 계정 관리자
  • 스토리지 관리자

4.1. 퍼블릭 클라우드 플랫폼에서 고가용성 클러스터를 사용할 때의 이점

사전 요구 사항

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. 필수 시스템 패키지

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

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

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 유틸리티 포함

4.3. 사용자 지정 가상 프라이빗 클라우드 네트워크 및 서브넷 생성

HA(고가용성) 기능으로 클러스터를 구성하려면 사용자 정의 VPC(가상 프라이빗 클라우드) 네트워크 및 서브넷이 필요합니다.

사전 요구 사항

프로세스

  1. GCP 콘솔을 시작합니다.
  2. 왼쪽 탐색 창에서 Networking (네트워킹)에서 VPC 네트워크를 선택합니다.
  3. VPC 네트워크 생성을 클릭합니다.
  4. VPC 네트워크의 이름을 입력합니다.
  5. New subnet 에서 클러스터를 생성할 리전에 사용자 지정 서브넷 을 만듭니다.
  6. 생성을 클릭합니다.

4.4. 기본 GCP 인스턴스 생성 및 구성

GCP 운영 및 보안 요구 사항을 준수하는 GCP 인스턴스를 생성하고 구성하려면 다음 단계를 완료하십시오.

프로세스

  1. 버킷의 압축 파일에서 이미지를 생성합니다.

    $ gcloud compute images create BaseImageName --source-uri gs://BucketName/BaseImageName.tar.gz
    Copy to Clipboard

    예제:

    $ gcloud compute images create rhel-76-server --source-uri gs://user-rhelha/rhel-server-76.tar.gz
    Created [https://www.googleapis.com/compute/v1/projects/MyProject/global/images/rhel-server-76].
    NAME            PROJECT                 FAMILY  DEPRECATED  STATUS
    rhel-76-server  rhel-ha-testing-on-gcp                      READY
    Copy to Clipboard
  2. 이미지에서 템플릿 인스턴스를 생성합니다. 기본 RHEL 인스턴스에 필요한 최소 크기는 n1-standard-2입니다. 추가 구성 옵션은 gcloud compute 인스턴스 생성 을 참조하십시오.

    $ gcloud compute instances create BaseInstanceName --can-ip-forward --machine-type n1-standard-2 --image BaseImageName --service-account ServiceAccountEmail
    Copy to Clipboard

    예제:

    $ gcloud compute instances create rhel-76-server-base-instance --can-ip-forward --machine-type n1-standard-2 --image rhel-76-server --service-account account@project-name-on-gcp.iam.gserviceaccount.com
    Created [https://www.googleapis.com/compute/v1/projects/rhel-ha-testing-on-gcp/zones/us-east1-b/instances/rhel-76-server-base-instance].
    NAME   ZONE   MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
    rhel-76-server-base-instance  us-east1-bn1-standard-2          10.10.10.3   192.227.54.211  RUNNING
    Copy to Clipboard
  3. SSH 터미널 세션을 사용하여 인스턴스에 연결합니다.

    $ ssh root@PublicIPaddress
    Copy to Clipboard
  4. RHEL 소프트웨어를 업데이트합니다.

    1. RHSM(Red Hat Subscription Manager)에 등록합니다.
    2. 서브스크립션 풀 ID를 활성화합니다(또는 --auto-attach 명령 사용).
    3. 모든 리포지토리를 비활성화합니다.

      # subscription-manager repos --disable=*
      Copy to Clipboard
    4. 다음 리포지토리를 활성화합니다.

      # subscription-manager repos --enable=rhel-10-server-rpms
      Copy to Clipboard
    5. dnf update 명령을 실행합니다.

      # dnf update -y
      Copy to Clipboard
  5. 실행 중인 인스턴스(인플레이스 설치)에 GCP Linux 게스트 환경을 설치합니다.

    자세한 내용은 게스트 환경 인플레이스 설치를 참조하십시오.

  6. CentOS/RHEL 옵션을 선택합니다.
  7. 명령 스크립트를 복사하여 명령 프롬프트에 붙여넣어 스크립트를 즉시 실행합니다.
  8. 인스턴스를 다음과 같이 구성합니다. 이러한 변경 사항은 사용자 정의 이미지에 대한 GCP 권장 사항을 기반으로 합니다. 자세한 내용은 gcloudcompute 이미지 목록을 참조하십시오.

    1. /etc/chrony.conf 파일을 편집하고 모든 NTP 서버를 제거합니다.
    2. 다음 NTP 서버를 추가합니다.

      metadata.google.internal iburst Google NTP server
      Copy to Clipboard
    3. 영구 네트워크 장치 규칙을 제거합니다.

      # rm -f /etc/udev/rules.d/70-persistent-net.rules
      # rm -f /etc/udev/rules.d/75-persistent-net-generator.rules
      Copy to Clipboard
    4. 자동으로 시작하도록 network 서비스를 설정합니다.

      # chkconfig network on
      Copy to Clipboard
    5. 자동으로 시작되도록 sshd 서비스를 설정합니다.

      # systemctl enable sshd
      # systemctl is-enabled sshd
      Copy to Clipboard
    6. 시간대를 UTC로 설정합니다.

      # ln -sf /usr/share/zoneinfo/UTC /etc/localtime
      Copy to Clipboard
    7. 선택 사항: /etc/ssh/ssh_config 파일을 편집하고 파일 끝에 다음 행을 추가합니다. 이렇게 하면 더 긴 비활성 기간 동안 SSH 세션이 활성화됩니다.

      # Server times out connections after several minutes of inactivity.
      # Keep alive ssh connections by sending a packet every 7 minutes.
      ServerAliveInterval 420
      Copy to Clipboard
    8. /etc/ssh/sshd_config 파일을 편집하고 필요한 경우 다음과 같이 변경합니다. ClientAliveInterval 420 설정은 선택 사항입니다. 이 설정은 비활성 기간 동안 SSH 세션을 활성 상태로 유지합니다.

      PermitRootLogin no
      PasswordAuthentication no
      AllowTcpForwarding yes
      X11Forwarding no
      PermitTunnel no
      # Compute times out connections after 10 minutes of inactivity.
      # Keep ssh connections alive by sending a packet every 7 minutes.
      ClientAliveInterval 420
      Copy to Clipboard
  9. 암호 액세스를 비활성화합니다.

    ssh_pwauth from 1 to 0.
    ssh_pwauth: 0
    Copy to Clipboard
    중요

    이전에는 SSH 세션 액세스를 허용하여 인스턴스를 구성할 수 있도록 암호 액세스를 활성화했습니다. 암호 액세스를 비활성화해야 합니다. 모든 SSH 세션 액세스는 암호 없이 액세스해야 합니다.

  10. 서브스크립션 관리자에서 인스턴스 등록을 취소합니다.

    # subscription-manager unregister
    Copy to Clipboard
  11. 쉘 기록을 정리합니다. 다음 절차에 대해 인스턴스를 계속 실행합니다.

    # export HISTSIZE=0
    Copy to Clipboard

4.5. 스냅샷 이미지 생성

GCP HA 인스턴스의 구성 및 디스크 데이터를 보존하려면 스냅샷을 생성합니다.

프로세스

  1. 실행 중인 인스턴스에서 데이터를 디스크에 동기화합니다.

    # sync
    Copy to Clipboard
  2. 호스트 시스템에서 스냅샷을 생성합니다.

    $ gcloud compute disks snapshot InstanceName --snapshot-names SnapshotName
    Copy to Clipboard
  3. 호스트 시스템에서 스냅샷에서 구성된 이미지를 생성합니다.

    $ gcloud compute images create ConfiguredImageFromSnapshot --source-snapshot SnapshotName
    Copy to Clipboard

4.6. HA 노드 템플릿 인스턴스 및 HA 노드 생성

스냅샷에서 이미지를 구성한 후 노드 템플릿을 생성할 수 있습니다. 그런 다음 이 템플릿을 사용하여 모든 HA 노드를 생성할 수 있습니다.

프로세스

  1. 인스턴스 템플릿을 생성합니다.

    $ gcloud compute instance-templates create InstanceTemplateName --can-ip-forward --machine-type n1-standard-2 --image ConfiguredImageFromSnapshot --service-account ServiceAccountEmailAddress
    Copy to Clipboard

    예제:

    $ gcloud compute instance-templates create rhel-10-instance-template --can-ip-forward --machine-type n1-standard-2 --image rhel-10-gcp-image --service-account account@project-name-on-gcp.iam.gserviceaccount.com
    Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/global/instanceTemplates/rhel-10-instance-template].
    NAME  MACHINE_TYPE   PREEMPTIBLE  CREATION_TIMESTAMP
    rhel-101-instance-template   n1-standard-2          2018-07-25T11:09:30.506-07:00
    Copy to Clipboard
  2. 하나의 영역에 여러 노드를 생성합니다.

    # gcloud compute instances create NodeName01 NodeName02 --source-instance-template InstanceTemplateName --zone RegionZone --network=NetworkName --subnet=SubnetName
    Copy to Clipboard

    예제:

    $ gcloud compute instances create rhel10-node-01 rhel10-node-02 rhel10-node-03 --source-instance-template rhel-10-instance-template --zone us-west1-b --network=projectVPC --subnet=range0
    Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/zones/us-west1-b/instances/rhel81-node-01].
    Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/zones/us-west1-b/instances/rhel81-node-02].
    Created [https://www.googleapis.com/compute/v1/projects/project-name-on-gcp/zones/us-west1-b/instances/rhel81-node-03].
    NAME            ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
    rhel81-node-01  us-west1-b  n1-standard-2               10.10.10.4   192.230.25.81   RUNNING
    rhel81-node-02  us-west1-b  n1-standard-2               10.10.10.5   192.230.81.253  RUNNING
    rhel81-node-03  us-east1-b  n1-standard-2               10.10.10.6   192.230.102.15  RUNNING
    Copy to Clipboard

4.7. GCP용 고가용성 패키지 및 에이전트 설치

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

프로세스

  1. Google Cloud Console에서 Compute Engine 을 선택한 다음 VM 인스턴스를 선택합니다.
  2. 인스턴스를 선택하고 SSH 옆에 있는 화살표를 클릭하고 View gcloud 명령 옵션을 선택합니다.
  3. 명령 프롬프트에 이 명령을 붙여넣어 암호 없이 인스턴스에 액세스할 수 있습니다.
  4. sudo 계정 액세스를 활성화하고 Red Hat Subscription Manager에 등록합니다.
  5. 서브스크립션 풀 ID를 활성화합니다(또는 --auto-attach 명령 사용).
  6. 모든 리포지토리를 비활성화합니다.

    # subscription-manager repos --disable=* 
    Copy to Clipboard
  7. 다음 리포지토리를 활성화합니다.

    # subscription-manager repos --enable=rhel-10-server-rpms
    # subscription-manager repos --enable=rhel-10-for-x86_64-highavailability-rpms
    Copy to Clipboard
  8. pcs pacemaker, 차단 에이전트 및 리소스 에이전트를 설치합니다.

    # dnf install -y pcs pacemaker fence-agents-gce resource-agents-gcp
    Copy to Clipboard
  9. 모든 패키지를 업데이트합니다.

    # dnf update -y
    Copy to Clipboard

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

다음 절차에 따라 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
  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
  3. 노드가 부팅될 때 클러스터의 각 노드에서 클러스터 서비스를 실행하도록 활성화합니다.

    참고

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

    [root@z1 ~]# pcs cluster enable --all
    Copy to Clipboard
  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

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

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

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

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

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

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

참고

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

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

pcs stonith list [filter]
Copy to Clipboard

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

pcs stonith describe [stonith_agent]
Copy to Clipboard

예를 들어 다음 명령은 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
주의

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

4.9.2. 차단 장치 생성

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

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

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

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

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

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

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

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

4.9.3. 펜싱 장치의 일반 속성

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

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

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

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

표 4.2. 펜싱 장치의 일반 속성
필드유형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(모든 장치가 모든 장치를 펜싱할 수 있음)

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

표 4.3. 펜싱 장치의 고급 속성
필드유형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 에서 작업을 중지하기 전에 재시도하는 횟수를 변경합니다.

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

표 4.4. 펜싱 동작을 결정하는 클러스터 속성
옵션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.9.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.9.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

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

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

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

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

    발생한 오류를 진단할 때 차단 장치에 수동으로 로그인할 때 지정한 옵션이 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

    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
    • sysrq-trigger 를 사용하여 크래시를 시뮬레이션하고 시스템에 패닉을 발생시킵니다. 그러나 커널 패닉을 트리거하면 데이터가 손실될 수 있습니다. 먼저 클러스터 리소스를 비활성화하는 것이 좋습니다.

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

4.9.6. 펜싱 수준 구성

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

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

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

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

pcs stonith level add level node devices
Copy to Clipboard

다음 예제에서는 장치 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
  2. rh7-2 노드에서 차단 장치 my_apc 에 대해 2의 펜싱 수준을 추가합니다.

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

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

펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트 를 참조하십시오.

4.9.6.1. 차단 수준 제거

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

pcs stonith level remove level  [node_id] [stonith_id] ... [stonith_id]
Copy to Clipboard
4.9.6.2. 펜스 수준 삭제

다음 명령은 지정된 노드 또는 stonith ID의 펜스 수준을 지웁니다. 노드 또는 stonith ID를 지정하지 않으면 모든 차단 수준이 지워집니다.

pcs stonith level clear [node]|stonith_id(s)]
Copy to Clipboard

다음 예제와 같이 두 개 이상의 stonith ID를 쉼표로 구분하고 공백을 사용하지 않아야 합니다.

# pcs stonith level clear dev_a,dev_b
Copy to Clipboard
4.9.6.3. 차단 수준에서 노드 및 장치 확인

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

pcs stonith level verify
Copy to Clipboard
4.9.6.4. 펜싱 토폴로지에서 노드 지정

노드 이름 및 해당 값에 적용되는 정규식으로 펜싱 토폴로지의 노드를 지정할 수 있습니다. 예를 들어 다음 명령은 노드 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

다음 명령은 노드 특성 일치를 사용하여 동일한 결과를 제공합니다.

# 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

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

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

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

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

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

프로세스

  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
  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
  3. 노드를 펜싱하는 데 두 장치가 모두 필요하므로 지정합니다.

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

4.9.8. 차단 장치 관리

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

4.9.8.1. 구성된 차단 장치 표시

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

pcs stonith config [stonith_id] [--full]
Copy to Clipboard
4.9.8.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
4.9.8.3. 차단 장치 수정 및 삭제

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

pcs stonith update stonith_id [stonith_device_options]
Copy to Clipboard

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

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

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

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

pcs stonith fence node [--off]
Copy to Clipboard

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

주의

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

pcs stonith confirm node
Copy to Clipboard
4.9.8.5. 차단 장치 비활성화

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

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

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

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

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

# pcs constraint location node1-ipmi avoids node1
Copy to Clipboard

4.9.9. 통합 펜스 장치와 함께 사용할 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.9.9.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

+---------------------------------------------|-------------------+
|    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

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

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

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

프로세스

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

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

    # systemctl restart systemd-logind.service
    Copy to Clipboard
  3. 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.
4.9.9.3. GRUB 2 파일에서 ACPI를 완전히 비활성화

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

중요

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

프로세스

GRUB 2 파일에서 ACPI를 비활성화하려면 다음 절차를 사용하십시오.

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

    # grubby --args=acpi=off --update-kernel=ALL
    Copy to Clipboard
  2. 노드를 재부팅합니다.
  3. 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.

4.10. 가상 IP 관리 리소스 에이전트 구성

gcp-vpc-move-vip 리소스 에이전트는 실행 중인 인스턴스에 보조 IP 주소(alias IP)를 연결합니다. 이 유동 IP 주소는 클러스터의 다른 노드 간에 할당할 수 있습니다.

# pcs resource describe gcp-vpc-move-vip
Copy to Clipboard

기본 서브넷 주소 범위 또는 보조 서브넷 주소 범위를 사용하도록 리소스 에이전트를 구성할 수 있습니다.

4.10.1. 기본 서브넷 주소 범위 구성

서브넷 내의 VM 또는 기타 리소스에 할당된 IP 주소 할당을 자동화하거나 관리해야 하는 경우 기본 서브넷 주소 범위를 사용할 수 있습니다. 기본 주소 범위가 올바르게 설정되고 기본 VPC(가상 프라이빗 네트워크) 서브넷의 안정적인 IP 주소로 사용하도록 구성합니다.

프로세스

  1. 사용되지 않은 내부 IP 주소와 CIDR 블록을 포함하여 aliasip 리소스를 생성합니다.

    # pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
    Copy to Clipboard

    예제:

    [root@rhel81-node-01 ~]# pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.10.200/32
    Copy to Clipboard
  2. 노드에서 IP를 관리하기 위한 IPaddr2 리소스를 생성합니다.

    # pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
    Copy to Clipboard

    예제:

    [root@rhel81-node-01 ~]# pcs resource create vip IPaddr2 nic=eth0 ip=10.10.10.200 cidr_netmask=32
    Copy to Clipboard
  3. vipgrp 아래에 네트워크 리소스를 그룹화합니다.

    # pcs resource group add vipgrp aliasip vip
    Copy to Clipboard

검증

  1. 활성 리소스와 vipgrp 그룹에서 다음을 확인합니다.

    # pcs status
    Copy to Clipboard
  2. 노드에서 이동 가능한 리소스를 확인합니다.

    # pcs resource move vip Node
    Copy to Clipboard

    예제:

    [root@rhel81-node-01 ~]# pcs resource move vip rhel81-node-03
    Copy to Clipboard
  3. vip 이 다른 노드에서 성공적으로 시작되었는지 확인합니다.

    # pcs status
    Copy to Clipboard

4.10.2. 보조 서브넷 주소 범위 구성

새 서브넷을 생성하지 않고 동일한 서브넷 내에서 추가 및 사전 정의된 범위의 IP 주소를 할당해야 하는 경우 보조 서브넷 주소 범위를 사용할 수 있습니다. 사용자 지정 라우팅과 같은 특정 목적에 유용합니다. 보조 서브넷 주소 범위를 사용하면 여러 IP 주소 범위가 있는 단일 서브넷에서 네트워크 트래픽을 관리할 수 있습니다.

사전 요구 사항

프로세스

  1. 보조 서브넷 주소 범위를 생성합니다.

    # gcloud compute networks subnets update SubnetName --region RegionName --add-secondary-ranges SecondarySubnetName=SecondarySubnetRange
    Copy to Clipboard

    예제:

    # gcloud compute networks subnets update range0 --region us-west1 --add-secondary-ranges range1=10.10.20.0/24
    Copy to Clipboard
  2. 보조 서브넷 주소 범위와 CIDR 블록에서 사용되지 않은 내부 IP 주소를 사용하여 aliasip 리소스를 생성합니다.

    # pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
    Copy to Clipboard

    예제:

    [root@rhel81-node-01 ~]# pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.20.200/32
    Copy to Clipboard
  3. 노드에서 IP를 관리하기 위한 IPaddr2 리소스를 생성합니다.

    # pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
    Copy to Clipboard

    예제:

    [root@rhel81-node-01 ~]# pcs resource create vip IPaddr2 nic=eth0 ip=10.10.20.200 cidr_netmask=32
    Copy to Clipboard
  4. vipgrp 아래에 네트워크 리소스를 그룹화합니다.

    # pcs resource group add vipgrp aliasip vip
    Copy to Clipboard

검증

  1. 활성 리소스와 vipgrp 그룹 아래의 및 가 있는지 확인합니다.

    # pcs status
    Copy to Clipboard
  2. 다른 노드에서 이동 가능한 리소스가 있는지 확인합니다.

    # pcs resource move vip Node
    Copy to Clipboard

    예제:

    [root@rhel81-node-01 ~]# pcs resource move vip rhel81-node-03
    Copy to Clipboard
  3. vip 이 다른 노드에서 성공적으로 시작되었는지 확인합니다.

    # pcs status
    Copy to Clipboard

법적 공지

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

© 2025 Red Hat