Google Cloud Platform에서 RHEL 배포 및 관리
GCP에서 RHEL 시스템 이미지 가져오기 및 RHEL 인스턴스 생성
초록
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
Jira를 통해 피드백 제출 (계정 필요)
- Jira 웹 사이트에 로그인합니다.
- 상단 탐색 바에서 생성을 클릭합니다.
- 요약 필드에 설명 제목을 입력합니다.
- 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 대화 상자 하단에서 생성 을 클릭합니다.
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 시스템을 배포하려면 다음을 수행해야 합니다.
요구 사항과 현재 출시에 따라 사용 사례에 맞는 최적의 클라우드 공급자를 선택합니다.
RHEL 인스턴스를 실행하는 데 필요한 인증된 클라우드 서비스 공급자(CCSP)는 다음과 같습니다.
- AWS(Amazon Web Services)
- GCP(Google Cloud Platform)
- 참고
이 문서에서는 GCP에 RHEL을 배포하는 프로세스를 구체적으로 설명합니다.
- 선택한 클라우드 플랫폼에 RHEL 클라우드 인스턴스를 생성합니다. 자세한 내용은 RHEL 클라우드 인스턴스 생성 방법을 참조하십시오.
- 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 버킷이 있습니다.
프로세스
텍스트 편집기를 사용하여 다음 내용으로
gcp-config.toml
구성 파일을 생성합니다.provider = "gcp" [settings] bucket = "GCP_BUCKET" region = "GCP_STORAGE_REGION" object = "OBJECT_KEY" credentials = "GCP_CREDENTIALS"
provider = "gcp" [settings] bucket = "GCP_BUCKET" region = "GCP_STORAGE_REGION" object = "OBJECT_KEY" credentials = "GCP_CREDENTIALS"
Copy to Clipboard Copied! -
GCP_BUCKET
은 기존 버킷을 가리킵니다. 업로드 중인 이미지의 중간 스토리지 오브젝트를 저장하는 데 사용됩니다. -
GCP_STORAGE_REGION
은 일반 Google 스토리지 영역과 이중 또는 멀티 영역입니다. -
OBJECT_KEY
는 중간 스토리지 오브젝트의 이름입니다. 업로드 전에는 존재하지 않아야 하며 업로드 프로세스가 완료되면 삭제됩니다. 오브젝트 이름이.tar.gz
로 끝나지 않으면 확장이 오브젝트 이름에 자동으로 추가됩니다. GCP_CREDENTIALS
는 GCP에서 다운로드한 인증 정보 JSON 파일의Base64
인코딩 체계입니다. 인증 정보에 따라 GCP에서 이미지를 업로드할 프로젝트가 결정됩니다.참고GCP로 인증하는 다른 메커니즘을 사용하는 경우
gcp-config.toml
파일에GCP_CREDENTIALS
를 지정하는 것은 선택 사항입니다. 기타 인증 방법은 GCP로 인증 을 참조하십시오.
-
GCP에서 다운로드한 JSON 파일에서
GCP_CREDENTIALS
를 검색합니다.sudo base64 -w 0 cee-gcp-nasa-476a1fa485b7.json
$ sudo base64 -w 0 cee-gcp-nasa-476a1fa485b7.json
Copy to Clipboard Copied! 추가 이미지 이름 및 클라우드 공급자 프로필을 사용하여 작성을 생성합니다.
sudo composer-cli compose start BLUEPRINT-NAME gce IMAGE_KEY gcp-config.toml
$ sudo composer-cli compose start BLUEPRINT-NAME gce IMAGE_KEY gcp-config.toml
Copy to Clipboard Copied! 이미지 빌드, 업로드 및 클라우드 등록 프로세스를 완료하는 데 최대 10분이 걸릴 수 있습니다.
검증
이미지 상태가 FINISHED인지 확인합니다.
sudo composer-cli compose status
$ sudo composer-cli compose status
Copy to Clipboard Copied!
2.2. RHEL 이미지 빌더가 다른 GCP 인증 정보의 인증 순서를 정렬하는 방법
RHEL 이미지 빌더에서 여러 다른 유형의 인증 정보를 사용하여 GCP로 인증할 수 있습니다. RHEL 이미지 빌더 구성이 여러 인증 정보 세트를 사용하여 GCP에서 인증하도록 설정된 경우 다음과 같은 기본 설정 순서대로 인증 정보를 사용합니다.
-
구성 파일에서
composer-cli
명령으로 지정된 인증 정보입니다. -
osbuild-composer
작업자 구성에 구성된 인증 정보입니다. 다음 옵션을 사용하여 자동으로 인증할 수 있는
Google GCP SDK
라이브러리의Application Default Credentials
(애플리케이션 기본 인증 정보)입니다.- GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 설정된 경우 애플리케이션 기본 자격 증명은 변수가 가리키는 파일에서 인증 정보를 로드하고 사용합니다.
애플리케이션 기본 인증 정보는 코드를 실행하는 리소스에 연결된 서비스 계정을 사용하여 인증을 시도합니다. 예를 들면 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"
[gcp] credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"
Copy to Clipboard Copied!
2.4. osbuild-composer 작업자 구성에서 인증 정보 지정
모든 이미지 빌드에 전역적으로 GCP에 사용하도록 GCP 인증 인증 정보를 구성할 수 있습니다. 이렇게 하면 이미지를 동일한 GCP 프로젝트로 가져오려면 GCP에 모든 이미지 업로드에 동일한 인증 정보를 사용할 수 있습니다.
프로세스
/etc/osbuild-worker/osbuild-worker.toml
작업자 구성에서 다음 인증 정보 값을 설정합니다.[gcp] credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"
[gcp] credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"
Copy to Clipboard Copied!
3장. GCP에서 RHEL 이미지를 Google Compute Engine 인스턴스로 배포
GCP(Google Cloud Platform)에서 RHEL 이미지를 사용하려면 이미지를 GCP 호환 형식으로 변환하고 이미지에서 VM을 배포하여 Google Compute Engine(GCE) VM으로 실행합니다. GCE 지원 형식에 RHEL 이미지를 생성, 사용자 정의 및 배포하려면 다음 방법 중 하나를 사용할 수 있습니다.
- Red Hat 이미지 빌더를 사용합니다. 자세한 내용은 GCP에 사용자 지정 GCE 이미지 준비 및 업로드를 참조하십시오.
- 지원되는 형식 이미지를 수동으로 생성하고 구성합니다. 이는 더 복잡한 프로세스이지만 더 세분화된 사용자 지정 옵션을 제공합니다. 자세한 내용은 다음 섹션을 참조하십시오.
GCP용 Red Hat 제품 인증 목록은 Google Cloud Platform의 Red Hat을 참조하십시오.
사전 요구 사항
- Red Hat 계정을 생성했습니다.
- GCP 계정을 등록하고 설정했습니다.
3.1. 퍼블릭 클라우드에 사용 가능한 RHEL 이미지 유형
인증된 클라우드 서비스 공급자(CCSP)에 RHEL 가상 머신 VM을 배포하려면 여러 옵션을 사용할 수 있습니다. 다음 표에는 이미지 유형에 사용할 수 있는 이미지 유형, 서브스크립션, 고려 사항 및 샘플 시나리오가 나열되어 있습니다.
사용자 지정 ISO 이미지를 배포하려면 Red Hat Image Builder를 사용할 수 있습니다. 이미지 빌더를 사용하면 선택한 CCSP 고유의 사용자 정의 이미지를 생성, 업로드 및 배포할 수 있습니다.
이미지 유형 | 서브스크립션 | 고려 사항 | 샘플 시나리오 |
---|---|---|---|
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의 용량 설정으로 변경했습니다.
프로세스
Red Hat Enterprise Linux VM을 구성합니다.
- CLI(명령줄)에서 설치하려면 VM의 요구 사항에 따라 기본 메모리, 네트워크 인터페이스 및 CPU를 설정해야 합니다. 자세한 내용은 명령줄을 사용하여 가상 머신 생성을참조하십시오.
- 웹 콘솔에서 설치하려면 웹 콘솔을 사용하여 가상 머신 생성을참조하십시오.
설치가 시작되면 다음을 수행합니다.
-
root
암호를 만듭니다. - 관리자 사용자 계정을 생성합니다.
-
-
설치가 완료되면 VM을 재부팅하고
root
계정에 로그인합니다. -
root
로 로그인한 후 이미지를 구성할 수 있습니다. VM을 등록하고 RHEL 리포지토리를 활성화합니다.
subscription-manager register --auto-attach
# subscription-manager register --auto-attach
Copy to Clipboard Copied!
검증
cloud-init
패키지가 설치되어 활성화되어 있는지 확인합니다.dnf install cloud-init systemctl enable --now cloud-init.service
# dnf install cloud-init # systemctl enable --now cloud-init.service
Copy to Clipboard Copied! - 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) 리소스 및 서비스를 관리할 수 있습니다.
사전 요구 사항
- Google Cloud SDK 를 다운로드, 추출 및 초기화했습니다.
프로세스
-
gcloud
CLI 유틸리티를 사용하여 프로젝트 및 인스턴스를 관리합니다. 프로젝트를 생성합니다.
gcloud projects create <example-gcp-project-id> --name <example-gcp-project>
# gcloud projects create <example-gcp-project-id> --name <example-gcp-project>
Copy to Clipboard Copied! 이 예제에서는 프로젝트 ID
<example-gcp-project-id>
와 프로젝트 이름이<example-gcp-project>
있는 프로젝트를 생성합니다.프로젝트 정보를 표시합니다.
gcloud compute <example-project-info> describe --project <example-project-name>
# gcloud compute <example-project-info> describe --project <example-project-name>
Copy to Clipboard Copied!
3.3.2. GCP에서 새 프로젝트 생성
RHEL 이미지를 GCP(Google Cloud Platform)에 업로드하려면 GCP에서 새 프로젝트를 생성해야 합니다. 프로젝트에서 할당된 Google Cloud 리소스를 관리합니다.
사전 요구 사항
- Google Cloud Platform 에 계정이 있습니다.
프로세스
- GCP 콘솔 을 시작합니다.
- Google Cloud Platform 오른쪽에 있는 드롭다운 메뉴를 클릭합니다.
- 팝업 메뉴에서 새 프로젝트 를 클릭합니다.
- 새 프로젝트 창에서 새 프로젝트의 이름을 입력합니다.
- 조직을 확인합니다. 필요한 경우 드롭다운 메뉴를 클릭하여 조직을 변경합니다.
- 상위 조직 또는 폴더의 위치를 확인합니다. 필요한 경우 찾아보기 를 클릭하여 이 값을 검색하고 변경합니다.
- 만들기 를 클릭하여 새 GCP 프로젝트를 생성합니다.
3.3.3. Google Cloud Storage에서 RHEL 이미지 생성 및 업로드
VM 이미지와 같은 오브젝트를 가져오고 저장할 GCP 스토리지 버킷을 생성합니다.
프로세스
Google 클라우드 콘솔에 로그인합니다.
gcloud auth login
# gcloud auth login
Copy to Clipboard Copied! 스토리지 버킷을 생성합니다.
gsutil mb gs://<example-bucket-name>
# gsutil mb gs://<example-bucket-name>
Copy to Clipboard Copied! 참고또는 Google Cloud Console을 사용하여 버킷을 생성할 수도 있습니다. 자세한 내용은 버킷 만들기를 참조하십시오.
생성할 이미지 이름, 기존 버킷 이름 및 이미지 이름을 지정합니다.
**gcloud compute images create my-image-name --source-uri gs://__<example-bucket-name>__/disk.raw.tar.gz**
# **gcloud compute images create my-image-name --source-uri gs://__<example-bucket-name>__/disk.raw.tar.gz**
Copy to Clipboard Copied! 참고또는 Google Cloud Console을 사용하여 이미지를 만들 수도 있습니다. 자세한 내용은 사용자 정의 이미지 생성, 삭제 및 사용 중단을 참조하십시오.
선택 사항: GCP 콘솔에서 이미지를 찾습니다.
- Google Cloud Console 배너의 왼쪽에 있는 탐색 메뉴를 클릭합니다.
- Compute Engine 을 선택한 다음 이미지를 선택합니다.
qemu-img
명령을 실행하여qcow2
이미지를원시
형식으로 변환합니다.qemu-img convert -f qcow2 -O raw rhel-10.0-sample.qcow2 disk.raw
# qemu-img convert -f qcow2 -O raw rhel-10.0-sample.qcow2 disk.raw
Copy to Clipboard Copied! 이미지를 압축합니다.
tar --format=oldgnu -Sczf disk.raw.tar.gz disk.raw
# tar --format=oldgnu -Sczf disk.raw.tar.gz disk.raw
Copy to Clipboard Copied! 기존 버킷에 이미지를 업로드합니다.
gsutil cp disk.raw.tar.gz gs://<example-bucket-name>
# gsutil cp disk.raw.tar.gz gs://<example-bucket-name>
Copy to Clipboard Copied! 참고업로드에 몇 분이 걸릴 수 있습니다.
- Google Cloud Platform 홈 화면에서 축소된 메뉴 아이콘을 클릭하고 스토리지를 선택한 다음 브라우저를 선택합니다.
disk.raw.tar.gz
가 나열된 버킷 이름을 클릭합니다.참고GCP 콘솔을 사용하여 이미지를 업로드할 수도 있습니다. 이렇게 하려면 버킷 이름을 클릭한 다음 파일 업로드 를 클릭합니다.
3.3.4. RHEL Google Compute Engine 인스턴스 시작 및 연결
이미지에서 GCE VM 인스턴스를 구성하려면 GCP 콘솔을 사용합니다.
프로세스
- GCP 콘솔 대시보드 페이지에서 Google Cloud Console 배너 의 왼쪽에 있는 탐색 메뉴를 클릭하고 Compute Engine 을 선택한 다음 이미지를 선택합니다.
- 이미지를 선택합니다.
- 인스턴스 생성을 클릭합니다.
- 인스턴스 만들기 페이지에서 인스턴스 의 이름을 입력합니다.
- 지역 및 영역을 선택합니다.
- 워크로드 요구 사항을 충족하거나 초과하는 머신 구성 을 선택합니다.
- 부팅 디스크가 이미지 이름을 지정했는지 확인합니다.
- 선택 사항: 방화벽 아래에서 HTTP 트래픽 허용 또는 HTTPS 트래픽 허용 을 선택합니다.
- 생성을 클릭합니다.
- VM 인스턴스에서 이미지를 찾습니다.
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
# gcloud compute instances create myinstance3 --zone=us-central1-a --image test-iso2-image
Copy to Clipboard Copied! 이 예제에서는 기존 이미지
test-iso2-image
를 기반으로 영역us-central1-a
에myinstance3
이라는 VM 인스턴스를 생성합니다. 자세한 내용은 gcloud 컴퓨팅 인스턴스 생성을 참조하십시오.ssh-keygen
유틸리티를 사용하여 공용 IP 주소를 사용하여 GCE와 함께 사용할 SSH 키 쌍을 생성합니다.ssh-keygen -t rsa -f ~/.ssh/google_compute_engine.pub
# ssh-keygen -t rsa -f ~/.ssh/google_compute_engine.pub
Copy to Clipboard Copied! - GCP 콘솔 대시보드 페이지에서 Google Cloud Console 배너 의 왼쪽에 있는 탐색 메뉴를 클릭하고 Compute Engine 을 선택한 다음 Metadata 를 선택합니다.
- SSH 키를 클릭한 다음 편집 을 클릭합니다.
-
~/.ssh/google_compute_engine.pub
파일에서 생성된 출력을 입력하고 저장을 클릭합니다. 인스턴스에 연결합니다.
ssh -i ~/.ssh/google_compute_engine <username>@<instance_external_ip>
# ssh -i ~/.ssh/google_compute_engine <username>@<instance_external_ip>
Copy to Clipboard Copied! 참고또는
gcloud compute config-ssh
명령을 실행하여 구성 파일을 인스턴스의 별칭으로 채울 수 있습니다. 별칭을 사용하면 인스턴스 이름별로 간단한 SSH 연결을 수행할 수 있습니다. 자세한 내용은 gcloud compute config-ssh 를 참조하십시오.
3.4. Red Hat 서브스크립션 첨부
subscription-manager
명령을 사용하여 Red Hat 서브스크립션을 RHEL 인스턴스에 등록하고 연결할 수 있습니다.
사전 요구 사항
- 유효한 Red Hat 계정이 있습니다.
프로세스
시스템을 등록합니다.
subscription-manager register --auto-attach
# subscription-manager register --auto-attach
Copy to Clipboard Copied! 서브스크립션을 연결합니다.
- 활성화 키를 사용하여 서브스크립션을 연결할 수 있습니다. 자세한 내용은 Red Hat 고객 포털 활성화 키 생성을 참조하십시오.
- 또는 서브스크립션 풀 ID(Pool ID)를 사용하여 서브스크립션을 수동으로 연결할 수 있습니다. 하이퍼바이저에 호스트 기반 서브스크립션 연결을 참조하십시오.
선택 사항: Red Hat Hybrid Cloud Console 의 인스턴스에 대한 다양한 시스템 메트릭을 수집하려면 Red Hat Insights 에 인스턴스를 등록할 수 있습니다.
insights-client register --display-name <display-name-value>
# insights-client register --display-name <display-name-value>
Copy to Clipboard Copied! 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 이미지 유형을 참조하십시오.
사전 요구 사항
- Red Hat 계정을 생성했습니다.
- GCP 계정을 등록하고 설정했습니다.
-
Red Hat Enterprise Linux 10 Server:
rhel-10-server-rpms/8Server/x86_64
-
Red Hat Enterprise Linux 10 Server(High Availability):
rhel-10-server-ha-rpms/8Server/x86_64
- 프로젝트에는 개별 사용자가 아닌 VM 인스턴스에 속하는 서비스 계정이 있어야 합니다. 별도 의 서비스 계정을 생성하는 대신 기본 서비스 계정 사용에 대한 정보는 Compute Engine 기본 서비스 계정 사용을 참조하십시오.
프로젝트 관리자가 사용자 지정 서비스 계정을 생성하는 경우 다음 역할에 대해 서비스 계정을 구성해야 합니다.
- 클라우드 추적 에이전트
- 컴퓨팅 관리자
- 컴퓨팅 네트워크 관리자
- 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 클러스터를 생성하고 관리하는
Corosync
및Kronosnet
- 사용자 지정 애플리케이션을 구성하고 관리하는 리소스 에이전트
- 베어 메탈 서버 및 가상 머신과 같은 플랫폼에서 클러스터를 사용하는 펜싱 에이전트
Red Hat HA 애드온은 노드 장애, 로드 밸런싱 및 노드 상태 점검과 같은 중요한 작업을 처리하여 내결함성 및 시스템 안정성을 제공합니다.
4.2. 필수 시스템 패키지
RHEL의 기본 이미지를 생성하고 구성하려면 호스트 시스템에 다음 패키지가 설치되어 있어야 합니다.
패키지 | 리포지터리 | 설명 |
---|---|---|
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용 시스템 관리 도구; |
다음 단계
- 사용자 정의 기본 이미지를 사용하여 RHEL 인스턴스 배포의 배포 단계를 따릅니다.
4.3. 사용자 지정 가상 프라이빗 클라우드 네트워크 및 서브넷 생성
HA(고가용성) 기능으로 클러스터를 구성하려면 사용자 정의 VPC(가상 프라이빗 클라우드) 네트워크 및 서브넷이 필요합니다.
사전 요구 사항
- Google Cloud SDK를 설치했습니다.
- 새 GCP 프로젝트를 생성했습니다.
프로세스
- GCP 콘솔을 시작합니다.
- 왼쪽 탐색 창에서 Networking (네트워킹)에서 VPC 네트워크를 선택합니다.
- VPC 네트워크 생성을 클릭합니다.
- VPC 네트워크의 이름을 입력합니다.
- New subnet 에서 클러스터를 생성할 리전에 사용자 지정 서브넷 을 만듭니다.
- 생성을 클릭합니다.
4.4. 기본 GCP 인스턴스 생성 및 구성
GCP 운영 및 보안 요구 사항을 준수하는 GCP 인스턴스를 생성하고 구성하려면 다음 단계를 완료하십시오.
프로세스
버킷의 압축 파일에서 이미지를 생성합니다.
gcloud compute images create BaseImageName --source-uri gs://BucketName/BaseImageName.tar.gz
$ gcloud compute images create BaseImageName --source-uri gs://BucketName/BaseImageName.tar.gz
Copy to Clipboard Copied! 예제:
gcloud compute images create rhel-76-server --source-uri gs://user-rhelha/rhel-server-76.tar.gz
$ 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 Copied! 이미지에서 템플릿 인스턴스를 생성합니다. 기본 RHEL 인스턴스에 필요한 최소 크기는 n1-standard-2입니다. 추가 구성 옵션은 gcloud compute 인스턴스 생성 을 참조하십시오.
gcloud compute instances create BaseInstanceName --can-ip-forward --machine-type n1-standard-2 --image BaseImageName --service-account ServiceAccountEmail
$ gcloud compute instances create BaseInstanceName --can-ip-forward --machine-type n1-standard-2 --image BaseImageName --service-account ServiceAccountEmail
Copy to Clipboard Copied! 예제:
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
$ 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 Copied! SSH 터미널 세션을 사용하여 인스턴스에 연결합니다.
ssh root@PublicIPaddress
$ ssh root@PublicIPaddress
Copy to Clipboard Copied! RHEL 소프트웨어를 업데이트합니다.
- RHSM(Red Hat Subscription Manager)에 등록합니다.
-
서브스크립션 풀 ID를 활성화합니다(또는
--auto-attach
명령 사용). 모든 리포지토리를 비활성화합니다.
subscription-manager repos --disable=*
# subscription-manager repos --disable=*
Copy to Clipboard Copied! 다음 리포지토리를 활성화합니다.
subscription-manager repos --enable=rhel-10-server-rpms
# subscription-manager repos --enable=rhel-10-server-rpms
Copy to Clipboard Copied! dnf update
명령을 실행합니다.dnf update -y
# dnf update -y
Copy to Clipboard Copied!
실행 중인 인스턴스(인플레이스 설치)에 GCP Linux 게스트 환경을 설치합니다.
자세한 내용은 게스트 환경 인플레이스 설치를 참조하십시오.
- CentOS/RHEL 옵션을 선택합니다.
- 명령 스크립트를 복사하여 명령 프롬프트에 붙여넣어 스크립트를 즉시 실행합니다.
인스턴스를 다음과 같이 구성합니다. 이러한 변경 사항은 사용자 정의 이미지에 대한 GCP 권장 사항을 기반으로 합니다. 자세한 내용은 gcloudcompute 이미지 목록을 참조하십시오.
-
/etc/chrony.conf
파일을 편집하고 모든 NTP 서버를 제거합니다. 다음 NTP 서버를 추가합니다.
metadata.google.internal iburst Google NTP server
metadata.google.internal iburst Google NTP server
Copy to Clipboard Copied! 영구 네트워크 장치 규칙을 제거합니다.
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/70-persistent-net.rules # rm -f /etc/udev/rules.d/75-persistent-net-generator.rules
Copy to Clipboard Copied! 자동으로 시작하도록 network 서비스를 설정합니다.
chkconfig network on
# chkconfig network on
Copy to Clipboard Copied! 자동으로 시작되도록
sshd 서비스를
설정합니다.systemctl enable sshd systemctl is-enabled sshd
# systemctl enable sshd # systemctl is-enabled sshd
Copy to Clipboard Copied! 시간대를 UTC로 설정합니다.
ln -sf /usr/share/zoneinfo/UTC /etc/localtime
# ln -sf /usr/share/zoneinfo/UTC /etc/localtime
Copy to Clipboard Copied! 선택 사항:
/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.
# 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 Copied! /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
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 Copied!
-
암호 액세스를 비활성화합니다.
ssh_pwauth from 1 to 0. ssh_pwauth: 0
ssh_pwauth from 1 to 0. ssh_pwauth: 0
Copy to Clipboard Copied! 중요이전에는 SSH 세션 액세스를 허용하여 인스턴스를 구성할 수 있도록 암호 액세스를 활성화했습니다. 암호 액세스를 비활성화해야 합니다. 모든 SSH 세션 액세스는 암호 없이 액세스해야 합니다.
서브스크립션 관리자에서 인스턴스 등록을 취소합니다.
subscription-manager unregister
# subscription-manager unregister
Copy to Clipboard Copied! 쉘 기록을 정리합니다. 다음 절차에 대해 인스턴스를 계속 실행합니다.
export HISTSIZE=0
# export HISTSIZE=0
Copy to Clipboard Copied!
4.5. 스냅샷 이미지 생성
GCP HA 인스턴스의 구성 및 디스크 데이터를 보존하려면 스냅샷을 생성합니다.
프로세스
실행 중인 인스턴스에서 데이터를 디스크에 동기화합니다.
sync
# sync
Copy to Clipboard Copied! 호스트 시스템에서 스냅샷을 생성합니다.
gcloud compute disks snapshot InstanceName --snapshot-names SnapshotName
$ gcloud compute disks snapshot InstanceName --snapshot-names SnapshotName
Copy to Clipboard Copied! 호스트 시스템에서 스냅샷에서 구성된 이미지를 생성합니다.
gcloud compute images create ConfiguredImageFromSnapshot --source-snapshot SnapshotName
$ gcloud compute images create ConfiguredImageFromSnapshot --source-snapshot SnapshotName
Copy to Clipboard Copied!
4.6. HA 노드 템플릿 인스턴스 및 HA 노드 생성
스냅샷에서 이미지를 구성한 후 노드 템플릿을 생성할 수 있습니다. 그런 다음 이 템플릿을 사용하여 모든 HA 노드를 생성할 수 있습니다.
프로세스
인스턴스 템플릿을 생성합니다.
gcloud compute instance-templates create InstanceTemplateName --can-ip-forward --machine-type n1-standard-2 --image ConfiguredImageFromSnapshot --service-account ServiceAccountEmailAddress
$ gcloud compute instance-templates create InstanceTemplateName --can-ip-forward --machine-type n1-standard-2 --image ConfiguredImageFromSnapshot --service-account ServiceAccountEmailAddress
Copy to Clipboard Copied! 예제:
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
$ 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 Copied! 하나의 영역에 여러 노드를 생성합니다.
gcloud compute instances create NodeName01 NodeName02 --source-instance-template InstanceTemplateName --zone RegionZone --network=NetworkName --subnet=SubnetName
# gcloud compute instances create NodeName01 NodeName02 --source-instance-template InstanceTemplateName --zone RegionZone --network=NetworkName --subnet=SubnetName
Copy to Clipboard Copied! 예제:
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
$ 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 Copied!
4.7. GCP용 고가용성 패키지 및 에이전트 설치
각 노드에서 GCP(Google Cloud Platform)에 Red Hat High Availability 클러스터를 구성하려면 고가용성 패키지 및 에이전트를 설치해야 합니다.
프로세스
- Google Cloud Console에서 Compute Engine 을 선택한 다음 VM 인스턴스를 선택합니다.
- 인스턴스를 선택하고 SSH 옆에 있는 화살표를 클릭하고 View gcloud 명령 옵션을 선택합니다.
- 명령 프롬프트에 이 명령을 붙여넣어 암호 없이 인스턴스에 액세스할 수 있습니다.
- sudo 계정 액세스를 활성화하고 Red Hat Subscription Manager에 등록합니다.
-
서브스크립션 풀 ID를 활성화합니다(또는
--auto-attach
명령 사용). 모든 리포지토리를 비활성화합니다.
subscription-manager repos --disable=*
# subscription-manager repos --disable=*
Copy to Clipboard Copied! 다음 리포지토리를 활성화합니다.
subscription-manager repos --enable=rhel-10-server-rpms subscription-manager repos --enable=rhel-10-for-x86_64-highavailability-rpms
# subscription-manager repos --enable=rhel-10-server-rpms # subscription-manager repos --enable=rhel-10-for-x86_64-highavailability-rpms
Copy to Clipboard Copied! pcs pacemaker
, 차단 에이전트 및 리소스 에이전트를 설치합니다.dnf install -y pcs pacemaker fence-agents-gce resource-agents-gcp
# dnf install -y pcs pacemaker fence-agents-gce resource-agents-gcp
Copy to Clipboard Copied! 모든 패키지를 업데이트합니다.
dnf update -y
# dnf update -y
Copy to Clipboard Copied!
4.8. 고가용성 클러스터 생성
다음 절차에 따라 Red Hat High Availability Add-On 클러스터를 생성합니다. 이 예제 절차에서는 z1.example.com
및 z2.example.com
노드로 구성된 클러스터를 생성합니다.
pcs
명령의 매개변수와 해당 매개변수에 대한 설명을 표시하려면 pcs
명령의 -h
옵션을 사용합니다.
프로세스
pcs
를 실행할 노드의 클러스터의 각 노드에 대해pcs
userhacluster
를 인증합니다.다음 명령은
z1.example.com
및z2.example.com
으로 구성된 2-노드 클러스터의 두 노드에 대해z1.example.com
의 사용자hacluster
를 인증합니다.pcs host auth z1.example.com z2.example.com
[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 Copied! z1.example.com
z2.example.com
노드로 구성된 2-노드 클러스터my_cluster
를 생성합니다. 이렇게 하면 클러스터 구성 파일이 클러스터의 두 노드에 모두 전파됩니다. 이 명령에는 클러스터의 두 노드에서 클러스터 서비스를 시작하는--start
옵션이 포함되어 있습니다.pcs cluster setup my_cluster --start z1.example.com z2.example.com
[root@z1 ~]# pcs cluster setup my_cluster --start z1.example.com z2.example.com
Copy to Clipboard Copied! 노드가 부팅될 때 클러스터의 각 노드에서 클러스터 서비스를 실행하도록 활성화합니다.
참고특정 환경의 경우 이 단계를 건너뛰어 클러스터 서비스를 비활성화 상태로 두도록 선택할 수 있습니다. 이를 통해 노드가 중단되면 노드가 클러스터에 다시 참여하기 전에 클러스터 또는 리소스의 문제가 해결되도록 할 수 있습니다. 클러스터 서비스를 비활성화한 상태로 두면 해당 노드에서
pcs cluster start
명령을 실행하여 노드를 재부팅할 때 서비스를 수동으로 시작해야 합니다.pcs cluster enable --all
[root@z1 ~]# pcs cluster enable --all
Copy to Clipboard Copied! pcs cluster status
명령을 사용하여 생성한 클러스터의 상태를 표시합니다.pcs cluster setup
명령의--start
옵션을 사용하여 클러스터 서비스를 시작하고 실행하기 전에 클러스터가 잠시 지연될 수 있으므로 클러스터와 해당 구성에서 후속 작업을 수행하기 전에 클러스터가 가동 및 실행 중인지 확인해야 합니다.pcs cluster status
[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 Copied!
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]
pcs stonith list [filter]
다음 명령을 실행하여 지정된 펜싱 에이전트의 옵션을 표시합니다.
pcs stonith describe [stonith_agent]
pcs stonith describe [stonith_agent]
예를 들어 다음 명령은 telnet/SSH를 통한 APC에 대한 차단 에이전트의 옵션을 표시합니다.
pcs stonith describe fence_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
메서드
옵션을 제공하는 차단 에이전트의 경우 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]
pcs stonith create stonith_id stonith_device_type [stonith_device_options] [op operation_action operation_options]
다음 명령은 단일 노드에 대한 단일 펜싱 장치를 생성합니다.
pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
# pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
일부 차단 장치는 단일 노드만 펜싱할 수 있지만 다른 장치는 여러 노드를 펜싱할 수 있습니다. 차단 장치를 생성할 때 지정하는 매개변수는 차단 장치가 지원하고 요구하는 사항에 따라 다릅니다.
- 일부 차단 장치는 펜싱할 수 있는 노드를 자동으로 결정할 수 있습니다.
-
차단 장치를 생성할 때
pcmk_host_list
매개 변수를 사용하여 해당 펜싱 장치에서 제어하는 모든 시스템을 지정할 수 있습니다. -
일부 차단 장치에는 호스트 이름을 펜스 장치에서 이해하는 사양에 매핑해야 합니다. 펜싱 장치를 생성할 때
pcmk_host_map
매개변수를 사용하여 호스트 이름을 매핑할 수 있습니다.
pcmk_host_list
및 pcmk_host_map
매개변수에 대한 자세한 내용은 펜싱 장치의 일반 속성을 참조하십시오.
펜스 장치를 구성한 후에는 장치를 테스트하여 올바르게 작동하는지 확인해야 합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.
4.9.3. 펜싱 장치의 일반 속성
펜싱 장치에 대해 설정할 수 있는 일반 속성과 펜싱 동작을 결정하는 다양한 클러스터 속성이 있습니다.
클러스터 노드는 fence 리소스가 시작 또는 중지되었는지 여부에 관계없이 모든 차단 장치로 다른 클러스터 노드를 펜싱할 수 있습니다. 리소스가 시작되었는지 여부는 다음 예외와 함께 사용할 수 있는지 여부에 관계없이 장치에 대한 반복 모니터만 제어합니다.
-
pcs stonith_id명령을 실행하여 펜싱 장치를 비활성화할
수 있습니다. 이렇게 하면 모든 노드가 해당 장치를 사용하지 않습니다. -
특정 노드에서 펜싱 장치를 사용하지 않도록
pcs 제약 조건 위치 … avoids 명령을 사용하여 펜싱 리소스에 대한 위치 제약 조건
을 구성할 수 있습니다. -
stonith-enabled=false
를 구성하면 펜싱이 완전히 비활성화됩니다. 그러나 Red Hat은 프로덕션 환경에 적합하지 않으므로 펜싱이 비활성화된 경우 클러스터를 지원하지 않습니다.
다음 표에서는 펜싱 장치에 대해 설정할 수 있는 일반 속성을 설명합니다.
필드 | 유형 | Default | 설명 |
---|---|---|---|
| string |
호스트 이름을 지원하지 않는 장치의 포트 번호에 호스트 이름 매핑. 예를 들어 | |
| string |
이 장치에서 제어하는 머신 목록입니다( | |
| string |
*
* 그렇지 않으면 차단 장치가 목록 작업을 지원하는 경우
* 그렇지 않으면 차단 장치가
* 다른 방법 |
장치에서 제어하는 머신을 결정하는 방법 허용되는 값: |
다음 표에는 펜싱 장치에 설정할 수 있는 추가 속성이 요약되어 있습니다. 이러한 속성은 고급 용도로만 사용됩니다.
필드 | 유형 | Default | 설명 |
---|---|---|---|
| string | port |
포트 대신 제공할 대체 매개변수입니다. 일부 장치는 표준 포트 매개 변수를 지원하지 않거나 추가 포트를 제공할 수 있습니다. 이를 사용하여 시스템을 펜싱해야 함을 나타내는 대체 장치별 매개 변수를 지정합니다. 값이 |
| string | reboot |
|
| time | 60s |
|
| integer | 2 |
시간 제한 기간 내에 |
| string | off |
|
| time | 60s |
|
| integer | 2 | 시간 제한 기간 내에 off 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker에서 중단하기 전에 작업을 재시도하는 횟수를 변경합니다. |
| string | list |
|
| time | 60s | 목록 작업에 사용할 대체 시간 초과를 지정합니다. 일부 장치는 정상보다 완료하는 데 훨씬 더 많은 시간이 필요합니다. 이를 사용하여 목록 작업에 대한 대체 장치별 시간 초과를 지정합니다. |
| integer | 2 |
시간 초과 기간 내에 |
| string | 모니터 |
|
| time | 60s |
|
| integer | 2 |
시간 초과 기간 내에 |
| string | status |
|
| time | 60s |
|
| integer | 2 | 시간 제한 기간 내에 status 명령을 재시도하는 최대 횟수입니다. 일부 장치는 여러 연결을 지원하지 않습니다. 장치가 다른 작업에서 사용 중이면 작업이 실패할 수 있으므로 시간이 남아 있는 경우 Pacemaker에서 작업을 자동으로 다시 시도합니다. 이 옵션을 사용하여 Pacemaker에서 종료하기 전에 상태 작업을 재시도하는 횟수를 변경합니다. |
| string | 0s |
펜싱 작업에 대한 기본 지연을 활성화하고 기본 지연 값을 지정합니다. |
| time | 0s |
펜싱 작업에 대한 임의의 지연을 활성화하고 결합된 기본 지연 및 임의 지연의 최대 값인 최대 지연을 지정합니다. 예를 들어 기본 지연이 3이고 |
| integer | 1 |
이 장치에서 병렬로 수행할 수 있는 최대 작업 수입니다. 클러스터 속성 |
| string | On |
고급 용도 전용의 경우: 에서 대신 실행할 대체 |
| time | 60s |
고급 용도 전용: |
| integer | 2 |
고급 용도 전용: 시간 제한 기간 내에 |
개별 차단 장치에 대해 설정할 수 있는 속성 외에도 다음 표에 설명된 대로 펜싱 동작을 결정하는 클러스터 속성을 설정할 수도 있습니다.
옵션 | Default | 설명 |
---|---|---|
| true |
중지할 수 없는 리소스가 있는 실패한 노드 및 노드를 펜싱해야 함을 나타냅니다. 데이터를 보호하려면 이 값을 설정해야 합니다.
Red Hat은 이 값이 |
| reboot |
펜싱 장치에 전달할 작업입니다. 허용되는 값: |
| 60s | STONITH 작업이 완료될 때까지 대기하는 시간입니다. |
| 10 | 클러스터가 더 이상 즉시 다시 시도하지 않기 전에 대상에 대해 펜싱이 실패할 수 있는 횟수입니다. |
| 노드가 하드웨어 워치독에 의해 종료되었다고 간주될 때까지 대기하는 최대 시간입니다. 이 값을 하드웨어 워치독 시간 제한의 두 배 값으로 설정하는 것이 좋습니다. 이 옵션은 워치독 전용 SBD 구성이 펜싱에 사용되는 경우에만 필요합니다. | |
| true | 펜싱 작업을 병렬로 수행할 수 있습니다. |
| 중지 |
자체 펜싱에 대한 알림을 받는 경우 클러스터 노드가 응답하는 방법을 결정합니다. 펜싱이 잘못 구성된 경우 클러스터 노드는 자체 펜싱에 대한 알림을 수신할 수 있습니다. 그렇지 않으면 클러스터 통신이 중단되지 않는 패브릭 펜싱을 사용하고 있습니다. 허용되는 값은 Pacemaker를 즉시 중지하고 중지된 상태를 유지하거나 로컬 노드를 즉시 재부팅하려고 시도하여 실패 시 다시 중지되도록 하는 것입니다.
이 속성의 기본값은 |
| 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을 펜싱할 때 지연 없이, node1
:0;node2:10snode2
를 펜싱할 때 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=1
및 pcs 속성이 priority-fencing-delay=15s
를 설정하고 다른 우선순위가 설정되지 않은 경우 다른 노드가 펜싱을 시작하기 전에 15초를 기다리므로 대부분의 리소스를 실행하는 노드가 계속 작동할 가능성이 더 높습니다. 특정 리소스가 나머지 리소스보다 중요한 경우 우선 순위를 높일 수 있습니다.
승격 가능한 복제의 승격된 역할을 실행하는 노드는 해당 복제본에 대한 우선 순위가 구성된 경우 추가 1 포인트를 가져옵니다.
펜싱 지연의 상호 작용
펜싱 지연 유형을 두 개 이상 설정하면 다음과 같은 결과가 발생합니다.
-
priority-fencing-delay
속성으로 설정된 지연은pcmk_delay_base
및pcmk_delay_max
차단 장치 속성의 지연에 추가됩니다. 이 동작은on-fail=fencing
이 리소스 모니터 작업에 설정된 경우와 같이 노드 손실 이외의 이유로 두 노드를 모두 펜싱해야 하는 경우 두 노드를 모두 지연할 수 있습니다. 이러한 지연을 조합하여 설정할 때priority-fencing-delay
속성을pcmk_delay_base
및pcmk_delay_max
의 최대 지연보다 훨씬 큰 값으로 설정합니다. 이 속성을 두 번으로 설정하면 이 값은 항상 안전합니다. -
Pacemaker 자체에서 예약한 펜싱만 펜싱 지연을 관찰합니다.
dlm_controld
및pcs 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 소프트오프 비활성화를 참조하십시오.
프로세스
다음 절차를 사용하여 차단 장치를 테스트합니다.
SSH, Telnet, HTTP 또는 장치를 수동으로 로그인하고 테스트하거나 지정된 출력을 확인하는 데 사용되는 원격 프로토콜을 사용합니다. 예를 들어 IPMI 사용 장치에 대한 펜싱을 구성하는 경우
ipmitool
을 사용하여 원격으로 로그인합니다. 펜싱 에이전트를 사용할 때 이러한 옵션이 필요할 수 있으므로 수동으로 로그인할 때 사용되는 옵션을 기록해 두십시오.차단 장치에 로그인할 수 없는 경우 장치가 ping 가능한지 확인합니다. 이 방화벽 구성에서는 차단 장치에 대한 액세스를 방지하고 펜싱 장치에서 원격 액세스가 활성화되고 인증 정보가 올바른지 확인합니다.
차단 에이전트 스크립트를 사용하여 차단 에이전트를 수동으로 실행합니다. 이 작업을 수행하려면 클러스터에서 장치를 구성하기 전에 이 단계를 수행할 수 있도록 클러스터 서비스가 실행되고 있지 않습니다. 이렇게 하면 계속하기 전에 펜스 장치가 올바르게 응답하는지 확인할 수 있습니다.
참고이러한 예에서는 iLO 장치에
fence_ipmilan
차단 에이전트 스크립트를 사용합니다. 사용할 실제 차단 에이전트와 해당 에이전트를 호출하는 명령은 서버 하드웨어에 따라 달라집니다. 지정할 옵션을 결정하려면 사용 중인 차단 에이전트의 도움말 페이지를 참조해야 합니다. 일반적으로 차단 장치의 로그인 및 암호 및 차단 장치와 관련된 기타 정보를 알아야 합니다.다음 예제에서는 실제로 펜싱하지 않고 다른 노드에서 차단 장치 인터페이스의 상태를 확인하기 위해
-o status
매개변수를 사용하여fence_ipmilan
차단 에이전트 스크립트를 실행하는 데 사용하는 형식을 보여줍니다. 이를 통해 노드를 재부팅하기 전에 장치를 테스트하고 작동하게 할 수 있습니다. 이 명령을 실행하는 경우 iLO 장치에 대한 권한을 켜거나 끄는 iLO 사용자의 이름과 암호를 지정합니다.fence_ipmilan -a ipaddress -l username -p password -o status
# fence_ipmilan -a ipaddress -l username -p password -o status
Copy to Clipboard Copied! 다음 예제에서는
-o reboot
매개변수를 사용하여fence_ipmilan
차단 에이전트 스크립트를 실행하는 데 사용하는 형식을 보여줍니다. 한 노드에서 이 명령을 실행하면 이 iLO 장치에서 관리하는 노드가 재부팅됩니다.fence_ipmilan -a ipaddress -l username -p password -o reboot
# fence_ipmilan -a ipaddress -l username -p password -o reboot
Copy to Clipboard Copied! 펜스 에이전트가 상태, 해제, on 또는 reboot 작업을 제대로 수행하지 못한 경우 하드웨어, 차단 장치 구성 및 명령의 구문을 확인해야 합니다. 또한 디버그 출력이 활성화된 상태에서 fence 에이전트 스크립트를 실행할 수 있습니다. 디버그 출력은 일부 펜싱 에이전트에서 차단 장치에 로그인할 때 펜싱 에이전트 스크립트가 실패하는지 확인하는 데 유용합니다.
fence_ipmilan -a ipaddress -l username -p password -o status -D /tmp/$(hostname)-fence_agent.debug
# fence_ipmilan -a ipaddress -l username -p password -o status -D /tmp/$(hostname)-fence_agent.debug
Copy to Clipboard Copied! 발생한 오류를 진단할 때 차단 장치에 수동으로 로그인할 때 지정한 옵션이 fence 에이전트 스크립트를 사용하여 차단 에이전트에 전달한 것과 동일한지 확인해야 합니다.
암호화된 연결을 지원하는 차단 에이전트의 경우 인증서 유효성 검사 실패로 인한 오류가 표시될 수 있으며, 호스트를 신뢰하거나 차단 에이전트의
ssl-insecure
매개변수를 사용해야 할 수 있습니다. 마찬가지로 대상 장치에서 SSL/TLS가 비활성화된 경우 차단 에이전트의 SSL 매개변수를 설정할 때 이를 고려해야 할 수 있습니다.참고테스트 중인 펜스 에이전트가 계속 실패하는 시스템 관리 장치의
fence_drac
,fence_ilo
또는 기타 일부 펜싱 에이전트인 경우fence_ipmilan
을 다시 시도합니다. 대부분의 시스템 관리 카드는 IPMI 원격 로그인을 지원하며 지원되는 유일한 펜싱 에이전트는fence_ipmilan
입니다.다음 예와 같이 클러스터에서 작업하는 것과 동일한 옵션을 사용하여 클러스터에서 차단 장치를 구성한 후 모든 노드에서
pcs stonith fence
명령을 사용하여 펜싱을 테스트합니다(또는 다른 노드에서 여러 번).pcs stonith fence
명령은 CIB에서 클러스터 구성을 읽고 fence 작업을 실행하도록 구성된 fence 에이전트를 호출합니다. 이렇게 하면 클러스터 구성이 올바른지 확인합니다.pcs stonith fence node_name
# pcs stonith fence node_name
Copy to Clipboard Copied! pcs stonith fence
명령이 제대로 작동하는 경우 차단 이벤트가 발생할 때 클러스터의 펜싱 구성이 작동해야 합니다. 명령이 실패하면 클러스터 관리가 검색한 구성을 통해 차단 장치를 호출할 수 없음을 의미합니다. 다음 문제를 확인하고 필요에 따라 클러스터 구성을 업데이트합니다.- 펜스 구성을 확인합니다. 예를 들어 호스트 맵을 사용한 경우 시스템에서 제공한 호스트 이름을 사용하여 노드를 찾을 수 있는지 확인해야 합니다.
- 장치의 암호 및 사용자 이름에 bash 쉘에서 잘못 해석할 수 있는 특수 문자가 포함되어 있는지 확인합니다. 따옴표로 묶은 암호와 사용자 이름을 입력했는지 확인하면 이 문제를 해결할 수 있습니다.
-
pcs stonith
명령에 지정한 정확한 IP 주소 또는 호스트 이름을 사용하여 장치에 연결할 수 있는지 확인합니다. 예를 들어 stonith 명령에 호스트 이름을 지정하지만 IP 주소를 사용하여 테스트하는 경우 유효한 테스트가 아닙니다. 펜스 장치에서 사용하는 프로토콜에 액세스할 수 있는 경우 해당 프로토콜을 사용하여 장치에 연결을 시도합니다. 예를 들어 많은 에이전트가 ssh 또는 telnet을 사용합니다. 장치를 구성할 때 제공한 인증 정보를 사용하여 장치에 연결을 시도하여 유효한 프롬프트가 표시되는지 확인하고 장치에 로그인할 수 있습니다.
모든 매개변수가 적합하지만 차단 장치에 연결하는 데 문제가 있는 경우 장치가 이를 제공하는 경우 사용자가 연결된 명령과 사용자가 실행한 명령을 표시하는 경우 차단 장치 자체에서 로깅을 확인할 수 있습니다. 또한
/var/log/messages
파일을 통해 stonith 및 error 인스턴스를 검색할 수 있으며 이로 인해 전송되는 내용에 대한 아이디어를 제공할 수 있지만 일부 에이전트는 추가 정보를 제공할 수 있습니다.
펜스 장치 테스트가 작동하고 클러스터가 가동되어 실행되면 실제 실패를 테스트합니다. 이렇게 하려면 토큰 손실을 시작해야 하는 클러스터에서 작업을 수행합니다.
네트워크를 끕니다. 네트워크를 사용하는 방법은 특정 구성에 따라 다릅니다. 대부분의 경우 호스트에서 네트워크 또는 전원 케이블을 물리적으로 끌어올 수 있습니다. 네트워크 장애 시뮬레이션에 대한 자세한 내용은 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
# 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 Copied! sysrq-trigger
를 사용하여 크래시를 시뮬레이션하고 시스템에 패닉을 발생시킵니다. 그러나 커널 패닉을 트리거하면 데이터가 손실될 수 있습니다. 먼저 클러스터 리소스를 비활성화하는 것이 좋습니다.echo c > /proc/sysrq-trigger
# echo c > /proc/sysrq-trigger
Copy to Clipboard Copied!
4.9.6. 펜싱 수준 구성
Pacemaker에서는 펜싱 토폴로지라는 기능을 통해 여러 장치가 있는 노드 펜싱을 지원합니다. 토폴로지를 구현하려면 일반적으로 개별 장치를 생성한 다음 구성의 펜싱 토폴로지 섹션에 하나 이상의 펜싱 수준을 정의합니다.
Pacemaker는 다음과 같이 펜싱 수준을 처리합니다.
- 각 수준은 1부터 오름차순으로 오름차순으로 시도됩니다.
- 장치가 실패하면 현재 수준에 대한 처리가 종료됩니다. 해당 수준의 추가 장치가 수행되지 않으며 다음 수준이 대신 시도됩니다.
- 모든 장치가 성공적으로 펜싱되면 해당 수준이 성공했으며 다른 수준은 시도하지 않습니다.
- 수준이 통과(성공)되거나 모든 수준을 시도한 경우 작업이 완료됩니다(실패).
다음 명령을 사용하여 노드에 펜싱 수준을 추가합니다. 장치는 해당 수준에서 노드에 대해 시도되는 쉼표로 구분된 stonith
ids 목록으로 제공됩니다.
pcs stonith level add level node devices
pcs stonith level add level node devices
다음 예제에서는 장치 my_ilo
가 실패하고 노드를 펜싱할 수 없는 경우 Pacemaker에서 my_apc
장치를 사용하려고 시도하도록 차단 수준을 설정합니다.
사전 요구 사항
-
rh7-2
노드에 대해my_ilo
라는 ilo fence 장치를 구성했습니다. -
rh7-2
노드에 대해my_apc
라는 apc 차단 장치를 구성했습니다.
프로세스
rh7-2
노드에서my_ilo
차단 장치에 대해 1의 펜싱 수준을 추가합니다.pcs stonith level add 1 rh7-2 my_ilo
# pcs stonith level add 1 rh7-2 my_ilo
Copy to Clipboard Copied! rh7-2
노드에서 차단 장치my_apc
에 대해 2의 펜싱 수준을 추가합니다.pcs stonith level add 2 rh7-2 my_apc
# pcs stonith level add 2 rh7-2 my_apc
Copy to Clipboard Copied! 현재 구성된 펜싱 수준을 나열합니다.
pcs stonith level
# pcs stonith level Node: rh7-2 Level 1 - my_ilo Level 2 - my_apc
Copy to Clipboard Copied!
펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트 를 참조하십시오.
4.9.6.1. 차단 수준 제거
다음 명령은 지정된 노드 및 장치의 펜스 수준을 제거합니다. 노드 또는 장치를 지정하지 않으면 지정한 차단 수준이 모든 노드에서 제거됩니다.
pcs stonith level remove level [node_id] [stonith_id] ... [stonith_id]
pcs stonith level remove level [node_id] [stonith_id] ... [stonith_id]
4.9.6.2. 펜스 수준 삭제
다음 명령은 지정된 노드 또는 stonith ID의 펜스 수준을 지웁니다. 노드 또는 stonith ID를 지정하지 않으면 모든 차단 수준이 지워집니다.
pcs stonith level clear [node]|stonith_id(s)]
pcs stonith level clear [node]|stonith_id(s)]
다음 예제와 같이 두 개 이상의 stonith ID를 쉼표로 구분하고 공백을 사용하지 않아야 합니다.
pcs stonith level clear dev_a,dev_b
# pcs stonith level clear dev_a,dev_b
4.9.6.3. 차단 수준에서 노드 및 장치 확인
다음 명령은 fence 수준에 지정된 모든 차단 장치 및 노드가 있는지 확인합니다.
pcs stonith level verify
pcs stonith level verify
4.9.6.4. 펜싱 토폴로지에서 노드 지정
노드 이름 및 해당 값에 적용되는 정규식으로 펜싱 토폴로지의 노드를 지정할 수 있습니다. 예를 들어 다음 명령은 노드 node1
,node2
및 node3
을 구성하여 차단 장치 apc1
및 apc2
, node4 , node4
,node5
, node6
을 사용하여 차단 장치 apc3
및 apc4
를 사용합니다.
pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2 pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4
# pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2
# pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4
다음 명령은 노드 특성 일치를 사용하여 동일한 결과를 제공합니다.
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
# 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
노드 속성에 대한 자세한 내용은 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. 중복 전원 공급 장치를 위한 펜싱 구성
중복 전원 공급 장치를 구성할 때 클러스터에서 호스트 재부팅을 시도할 때 두 전원 공급 장치를 모두 꺼야 전원 공급 장치를 다시 켜야 합니다.
노드의 전원이 완전히 손실되지 않으면 노드에서 해당 리소스를 해제하지 못할 수 있습니다. 이렇게 하면 노드가 이러한 리소스에 동시에 액세스하고 손상될 수 있습니다.
각 장치를 한 번만 정의하고 노드를 펜싱하는 데 둘 다 필요함을 지정해야 합니다.
프로세스
첫 번째 차단 장치를 생성합니다.
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"
# 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 Copied! 두 번째 차단 장치를 생성합니다.
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"
# 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 Copied! 노드를 펜싱하는 데 두 장치가 모두 필요하므로 지정합니다.
pcs stonith level add 1 node1.example.com apc1,apc2 pcs stonith level add 1 node2.example.com apc1,apc2
# pcs stonith level add 1 node1.example.com apc1,apc2 # pcs stonith level add 1 node2.example.com apc1,apc2
Copy to Clipboard Copied!
4.9.8. 차단 장치 관리
pcs
명령줄 인터페이스는 차단 장치를 구성한 후 사용할 수 있는 다양한 명령을 제공합니다.
4.9.8.1. 구성된 차단 장치 표시
다음 명령은 현재 구성된 모든 차단 장치를 보여줍니다. stonith_id 가 지정된 경우 명령은 구성된 펜싱 장치에 대한 옵션만 표시합니다. --full
옵션을 지정하면 구성된 모든 펜싱 옵션이 표시됩니다.
pcs stonith config [stonith_id] [--full]
pcs stonith config [stonith_id] [--full]
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
# 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
4.9.8.3. 차단 장치 수정 및 삭제
다음 명령을 사용하여 현재 구성된 펜싱 장치에 옵션을 수정하거나 추가합니다.
pcs stonith update stonith_id [stonith_device_options]
pcs stonith update stonith_id [stonith_device_options]
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
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
다음 명령을 사용하여 현재 구성에서 펜싱 장치를 제거합니다.
pcs stonith delete stonith_id
pcs stonith delete stonith_id
4.9.8.4. 수동으로 클러스터 노드 펜싱
다음 명령을 사용하여 노드를 수동으로 펜싱할 수 있습니다. --off
옵션을 지정하면 off
API 호출을 사용하여 stonith를 사용하여 노드를 재부팅하지 않고 꺼집니다.
pcs stonith fence node [--off]
pcs stonith fence node [--off]
펜스 장치가 더 이상 활성 상태가 아니더라도 노드를 펜싱할 수 없는 경우 클러스터는 노드의 리소스를 복구하지 못할 수 있습니다. 이 경우 노드의 전원이 꺼졌는지 수동으로 확인한 후 다음 명령을 입력하여 노드의 전원이 꺼졌는지 확인하고 복구를 위해 해당 리소스를 해제할 수 있습니다.
지정한 노드가 실제로 꺼져 있지 않지만 클러스터에 의해 일반적으로 제어되는 클러스터 소프트웨어 또는 서비스를 실행하면 데이터 손상 및 클러스터 오류가 발생합니다.
pcs stonith confirm node
pcs stonith confirm node
4.9.8.5. 차단 장치 비활성화
펜싱 장치를 비활성화하려면 pcs stonith disable
명령을 실행합니다.
다음 명령은 차단 장치 myapc
를 비활성화합니다.
pcs stonith disable myapc
# pcs stonith disable myapc
4.9.8.6. 노드에서 펜싱 장치를 사용하지 못하도록 방지
특정 노드가 펜싱 장치를 사용하지 않도록 하려면 펜싱 리소스의 위치 제약 조건을 구성할 수 있습니다.
다음 예제에서는 fence 장치 node1-ipmi
가 node1
에서 실행되지 않도록 합니다.
pcs constraint location node1-ipmi avoids node1
# pcs constraint location node1-ipmi avoids node1
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를 비활성화할 수 있습니다.
-
/etc/systemd/logind.conf
파일에HandlePowerKey=ignore
를 설정하고 logind.conf 파일에서 ACPI 소프트 오프 비활성화에 설명된 대로 노드가 펜싱 시 즉시 꺼졌는지 확인합니다. 이는 ACPI Soft-Off를 비활성화하는 첫 번째 대체 방법입니다. GRUB 2 파일에서 ACPI 비활성화에 설명된 대로
acpi=off
를 커널 부팅 명령줄에 추가합니다. 이는 ACPI soft-Off를 비활성화하는 두 번째 대체 방법입니다. 기본 설정 또는 첫 번째 대체 방법을 사용할 수 없습니다.중요이 방법은 ACPI를 완전히 비활성화합니다. ACPI를 완전히 비활성화하면 일부 컴퓨터가 올바르게 부팅되지 않습니다. 다른 방법이 클러스터에 효과가 없는 경우에만 이 방법을 사용합니다.
4.9.9.1. BIOS로 ACPI soft-Off 비활성화
다음 절차에 따라 각 클러스터 노드의 BIOS를 구성하여 ACPI Soft-Off를 비활성화할 수 있습니다.
BIOS로 ACPI Soft-Off를 비활성화하는 절차는 서버 시스템마다 다를 수 있습니다. 하드웨어 설명서에서 이 절차를 확인해야 합니다.
프로세스
-
노드를 재부팅하고
BIOS CMOS 설정 유틸리티
프로그램을 시작합니다. - Power 메뉴(또는 동등한 전원 관리 메뉴)로 이동합니다.
Power 메뉴에서
PWR-BTTN
함수(또는 이에 해당하는 경우)를Instant-Off
로 설정합니다(또는 지연 없이 전원 버튼을 사용하여 노드를 끄는 동등한 설정). 아래BIOS CMOS 설정
사용률 예제에는PWR-BTTN이
로 설정된Instant-Off
ACPI Function
이Enabled
로 설정된 Power 메뉴가 표시되어 있습니다.참고ACPI 기능
,PWR-BTTN에 의한 soft-Off에
해당하는 것으로,Instant-Off
는 컴퓨터마다 다를 수 있습니다. 그러나 이 절차의 목적은 컴퓨터를 지연 없이 전원 버튼을 통해 꺼지도록 BIOS를 구성하는 것입니다.-
BIOS CMOS 설정 유틸리티
프로그램을 종료하고 BIOS 구성을 저장합니다. - 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.
BIOS CMOS 설정 유틸리티
:
`Soft-Off by PWR-BTTN` set to `Instant-Off`
`Soft-Off by PWR-BTTN` set to
`Instant-Off`
+---------------------------------------------|-------------------+ | 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 | | | | | | | | +---------------------------------------------|-------------------+
+---------------------------------------------|-------------------+
| 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 | |
| | |
| | |
+---------------------------------------------|-------------------+
이 예에서는 ACPI Function
이 Enabled
로 설정되고 PWR-BTTN이
-Off를 보여줍니다.
Instant-Off
로 설정된 soft
4.9.9.2. logind.conf 파일에서 ACPI soft-Off 비활성화
/etc/systemd/logind.conf
파일에서 전원 키 전달을 비활성화하려면 다음 절차를 사용하십시오.
프로세스
/etc/systemd/logind.conf
파일에 다음 구성을 정의합니다.HandlePowerKey=ignore
HandlePowerKey=ignore
Copy to Clipboard Copied! systemd-logind
서비스를 다시 시작하십시오.systemctl restart systemd-logind.service
# systemctl restart systemd-logind.service
Copy to Clipboard Copied! - 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.
4.9.9.3. GRUB 2 파일에서 ACPI를 완전히 비활성화
커널의 GRUB 메뉴 항목에 acpi=off
를 추가하여 ACPI Soft-Off를 비활성화할 수 있습니다.
이 방법은 ACPI를 완전히 비활성화합니다. ACPI를 완전히 비활성화하면 일부 컴퓨터가 올바르게 부팅되지 않습니다. 다른 방법이 클러스터에 효과가 없는 경우에만 이 방법을 사용합니다.
프로세스
GRUB 2 파일에서 ACPI를 비활성화하려면 다음 절차를 사용하십시오.
grubby
툴의--update-kernel
옵션과 함께--args
옵션을 사용하여 다음과 같이 각 클러스터 노드의grub.cfg
파일을 변경합니다.grubby --args=acpi=off --update-kernel=ALL
# grubby --args=acpi=off --update-kernel=ALL
Copy to Clipboard Copied! - 노드를 재부팅합니다.
- 펜싱 시 노드가 즉시 꺼졌는지 확인합니다. 펜스 장치를 테스트하는 방법에 대한 자세한 내용은 차단 장치 테스트를 참조하십시오.
4.10. 가상 IP 관리 리소스 에이전트 구성
gcp-vpc-move-vip
리소스 에이전트는 실행 중인 인스턴스에 보조 IP 주소(alias IP)를 연결합니다. 이 유동 IP 주소는 클러스터의 다른 노드 간에 할당할 수 있습니다.
pcs resource describe gcp-vpc-move-vip
# pcs resource describe gcp-vpc-move-vip
기본 서브넷 주소 범위 또는 보조 서브넷 주소 범위를 사용하도록 리소스 에이전트를 구성할 수 있습니다.
4.10.1. 기본 서브넷 주소 범위 구성
서브넷 내의 VM 또는 기타 리소스에 할당된 IP 주소 할당을 자동화하거나 관리해야 하는 경우 기본 서브넷 주소 범위를 사용할 수 있습니다. 기본 주소 범위가 올바르게 설정되고 기본 VPC(가상 프라이빗 네트워크) 서브넷의 안정적인 IP 주소로 사용하도록 구성합니다.
프로세스
사용되지 않은 내부 IP 주소와 CIDR 블록을 포함하여
aliasip
리소스를 생성합니다.pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
# pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
Copy to Clipboard Copied! 예제:
pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.10.200/32
[root@rhel81-node-01 ~]# pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.10.200/32
Copy to Clipboard Copied! 노드에서 IP를 관리하기 위한
IPaddr2
리소스를 생성합니다.pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
# pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
Copy to Clipboard Copied! 예제:
pcs resource create vip IPaddr2 nic=eth0 ip=10.10.10.200 cidr_netmask=32
[root@rhel81-node-01 ~]# pcs resource create vip IPaddr2 nic=eth0 ip=10.10.10.200 cidr_netmask=32
Copy to Clipboard Copied! vipgrp
아래에 네트워크 리소스를 그룹화합니다.pcs resource group add vipgrp aliasip vip
# pcs resource group add vipgrp aliasip vip
Copy to Clipboard Copied!
검증
활성 리소스와
vipgrp
그룹에서 다음을 확인합니다.pcs status
# pcs status
Copy to Clipboard Copied! 노드에서 이동 가능한 리소스를 확인합니다.
pcs resource move vip Node
# pcs resource move vip Node
Copy to Clipboard Copied! 예제:
pcs resource move vip rhel81-node-03
[root@rhel81-node-01 ~]# pcs resource move vip rhel81-node-03
Copy to Clipboard Copied! vip
이 다른 노드에서 성공적으로 시작되었는지 확인합니다.pcs status
# pcs status
Copy to Clipboard Copied!
4.10.2. 보조 서브넷 주소 범위 구성
새 서브넷을 생성하지 않고 동일한 서브넷 내에서 추가 및 사전 정의된 범위의 IP 주소를 할당해야 하는 경우 보조 서브넷 주소 범위를 사용할 수 있습니다. 사용자 지정 라우팅과 같은 특정 목적에 유용합니다. 보조 서브넷 주소 범위를 사용하면 여러 IP 주소 범위가 있는 단일 서브넷에서 네트워크 트래픽을 관리할 수 있습니다.
사전 요구 사항
- 사용자 지정 네트워크 및 서브넷을 생성했습니다.
선택 사항: Google Cloud SDK를 설치했습니다. 자세한 내용은 Google Cloud SDK 설치를 참조하십시오.
그러나 Google Cloud 웹 콘솔에서 활성화할 수 있는 터미널의 다음 절차에서
gcloud
명령을 사용할 수 있습니다.
프로세스
보조 서브넷 주소 범위를 생성합니다.
gcloud compute networks subnets update SubnetName --region RegionName --add-secondary-ranges SecondarySubnetName=SecondarySubnetRange
# gcloud compute networks subnets update SubnetName --region RegionName --add-secondary-ranges SecondarySubnetName=SecondarySubnetRange
Copy to Clipboard Copied! 예제:
gcloud compute networks subnets update range0 --region us-west1 --add-secondary-ranges range1=10.10.20.0/24
# gcloud compute networks subnets update range0 --region us-west1 --add-secondary-ranges range1=10.10.20.0/24
Copy to Clipboard Copied! 보조 서브넷 주소 범위와 CIDR 블록에서 사용되지 않은 내부 IP 주소를 사용하여
aliasip
리소스를 생성합니다.pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
# pcs resource create aliasip gcp-vpc-move-vip alias_ip=UnusedIPaddress/CIDRblock
Copy to Clipboard Copied! 예제:
pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.20.200/32
[root@rhel81-node-01 ~]# pcs resource create aliasip gcp-vpc-move-vip alias_ip=10.10.20.200/32
Copy to Clipboard Copied! 노드에서 IP를 관리하기 위한
IPaddr2
리소스를 생성합니다.pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
# pcs resource create vip IPaddr2 nic=interface ip=AliasIPaddress cidr_netmask=32
Copy to Clipboard Copied! 예제:
pcs resource create vip IPaddr2 nic=eth0 ip=10.10.20.200 cidr_netmask=32
[root@rhel81-node-01 ~]# pcs resource create vip IPaddr2 nic=eth0 ip=10.10.20.200 cidr_netmask=32
Copy to Clipboard Copied! vipgrp
아래에 네트워크 리소스를 그룹화합니다.pcs resource group add vipgrp aliasip vip
# pcs resource group add vipgrp aliasip vip
Copy to Clipboard Copied!
검증
활성 리소스와
vipgrp
그룹 아래의 및 가 있는지 확인합니다.pcs status
# pcs status
Copy to Clipboard Copied! 다른 노드에서 이동 가능한 리소스가 있는지 확인합니다.
pcs resource move vip Node
# pcs resource move vip Node
Copy to Clipboard Copied! 예제:
pcs resource move vip rhel81-node-03
[root@rhel81-node-01 ~]# pcs resource move vip rhel81-node-03
Copy to Clipboard Copied! vip
이 다른 노드에서 성공적으로 시작되었는지 확인합니다.pcs status
# pcs status
Copy to Clipboard Copied!