설치 구성

프로세스

1. https://mirror.openshift.com/pub/openshift-v4/clients/butane/ Butane 이미지 다운로드 페이지로 이동합니다.

2. butane 바이너리를 가져옵니다.

   1. Butane의 최신 버전의 경우 최신 butane 이미지를 현재 디렉터리에 저장합니다.

      $ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane --output butane

   2. 선택 사항: butane을 설치할 특정 아키텍처 유형(예: arch64 또는 ppc64le)에 적절한 URL을 지정합니다. 예를 들면 다음과 같습니다.

      $ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane-aarch64 --output butane

3. 다운로드한 바이너리 파일을 실행 가능하게 합니다.

   $ chmod +x butane

4. butane 바이너리 파일을 PATH의 디렉터리로 이동합니다.

   PATH를 확인하려면 터미널을 열고 다음 명령을 실행합니다.

   $ echo $PATH

프로세스

1. Butane 구성 파일을 생성합니다. 다음 예제에서는 시스템 콘솔을 구성하여 커널 디버그 메시지를 표시하고 chrony 시간 서비스에 대한 사용자 지정 설정을 지정하는 99-worker-custom.bu라는 파일을 생성합니다.

   variant: openshift
   version: 4.17.0
   metadata:
     name: 99-worker-custom
     labels:
       machineconfiguration.openshift.io/role: worker
   openshift:
     kernel_arguments:
       - loglevel=7
   storage:
     files:
       - path: /etc/chrony.conf
         mode: 0644
         overwrite: true
         contents:
           inline: |
             pool 0.rhel.pool.ntp.org iburst
             driftfile /var/lib/chrony/drift
             makestep 1.0 3
             rtcsync
             logdir /var/log/chrony

   참고

   99-worker-custom.bu 파일은 작업자 노드에 대한 머신 구성을 생성하도록 설정되어 있습니다. 컨트롤 플레인 노드에 배포하려면 역할을 worker에서 master로 변경하십시오. 이 두 가지 작업을 수행하려면 여러유형의 배포에 서로 다른 파일 이름을 사용하여 전체 프로세스를 반복할 수 있습니다.

2. 이전 단계에서 생성한 파일을 Butane으로 지정하여 MachineConfig 오브젝트를 생성합니다.

   $ butane 99-worker-custom.bu -o ./99-worker-custom.yaml

   머신 구성을 완료하기 위해 MachineConfig 오브젝트 YAML 파일이 생성됩니다.

3. 향후 MachineConfig 오브젝트를 업데이트해야 하는 경우 Butane 구성을 저장합니다.

4. 클러스터가 아직 작동하지 않은 경우 매니페스트 파일을 생성하고 MachineConfig 오브젝트 YAML 파일을 openshift 디렉토리에 추가합니다. 클러스터가 이미 실행중인 경우 다음과 같이 파일을 적용합니다.

   $ oc create -f 99-worker-custom.yaml

프로세스

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

   # subscription-manager register

2. RHEL 8 시스템에 서브스크립션을 연결합니다.

   # subscription-manager attach --auto

3. 소프트웨어 및 컨테이너를 빌드하는 데 필요한 소프트웨어를 설치합니다.

   # yum install podman make git -y

4. kmod-via-containers 저장소를 복제합니다.

   1. 저장소의 폴더를 만듭니다.

      $ mkdir kmods; cd kmods

   2. 저장소를 복제합니다.

      $ git clone https://github.com/kmods-via-containers/kmods-via-containers

5. RHEL 8 빌드 호스트에 KVC 프레임 워크 인스턴스를 설치하여 모듈을 테스트합니다. kmods-via-container systemd 서비스가 추가되어 로드됩니다.

   1. kmod-via-containers 디렉터리로 변경합니다.

      $ cd kmods-via-containers/

   2. KVC 프레임워크 인스턴스를 설치합니다.

      $ sudo make install

   3. systemd 관리자 설정을 다시로드합니다.

      $ sudo systemctl daemon-reload

6. 커널 모듈의 소스 코드를 가져옵니다. 소스 코드는 제어할 수 없지만 다른 사람이 제공하는 타사 모듈을 빌드하는 데 사용될 수 있습니다. 다음과 같이 시스템에 복제할 수있는 kvc-simple-kmod 예제에 표시된 내용과 유사한 내용이 필요합니다.

   $ cd .. ; git clone https://github.com/kmods-via-containers/kvc-simple-kmod

7. 설정 파일 simple-kmod.conf을 편집하고 Dockerfile의 이름을 Dockerfile.rhel로 변경합니다.

   1. kvc-simple-kmod 디렉터리로 변경합니다.

      $ cd kvc-simple-kmod

   2. Dockerfile의 이름을 바꿉니다.

      $ cat simple-kmod.conf

      Dockerfile 예

      KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git"
      KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel
      KMOD_SOFTWARE_VERSION=dd1a7d4
      KMOD_NAMES="simple-kmod simple-procfs-kmod"

8. 커널 모듈의 kmods-via-containers @.service 인스턴스 (이 예제에서는 simple-kmod)를 만듭니다.

   $ sudo make install

9. kmods-via-containers @.service 인스턴스를 활성화합니다.

   $ sudo kmods-via-containers build simple-kmod $(uname -r)

10. systemd 서비스를 활성화하고 시작합니다.

    $ sudo systemctl enable kmods-via-containers@simple-kmod.service --now

    1. 서비스 상태를 확인합니다.

       $ sudo systemctl status kmods-via-containers@simple-kmod.service

       출력 예

       ● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod
          Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service;
                 enabled; vendor preset: disabled)
          Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...

11. 커널 모듈이 로드되었는지 확인하려면 lsmod 명령을 사용하여 모듈을 나열하십시오.

    $ lsmod | grep simple_

    출력 예

    simple_procfs_kmod     16384  0
    simple_kmod            16384  0

12. 선택사항. 다른 방법을 사용하여 simple-kmod 예제가 작동하는지 확인합니다.

    • dmesg를 사용하여 커널 링 버퍼에 "Hello world"메시지를 찾으십시오.

      $ dmesg | grep 'Hello world'

      출력 예

      [ 6420.761332] Hello world from simple_kmod.

    • /proc에서 simple-procfs-kmod의 값을 확인합니다.

      $ sudo cat /proc/simple-procfs-kmod

      출력 예

      simple-procfs-kmod number = 0

    • spkut 명령을 실행하여 모듈에 대한 자세한 정보를 가져옵니다.

      $ sudo spkut 44

      출력 예

      KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64
      Running userspace wrapper using the kernel module container...
      + podman run -i --rm --privileged
         simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44
      simple-procfs-kmod number = 0
      simple-procfs-kmod number = 44

프로세스

1. TPM v2를 사용하여 클러스터를 암호화하려면 각 노드의 호스트 펌웨어에서 TPM v2 암호화를 활성화해야 하는지 확인합니다. 이는 대부분의 Dell 시스템에서 필요합니다. 특정 시스템에 대한 설명서를 확인합니다.

2. Tang을 사용하여 클러스터를 암호화하려면 다음 준비 단계를 수행하십시오.

   1. Tang 서버를 설정하거나 기존 서버에 액세스합니다. 자세한 내용은 Network-bound disk encryption에서 참조하십시오.

   2. 아직 설치되지 않은 경우 RHEL 8 시스템에 clevis 패키지를 설치합니다.

      $ sudo yum install clevis

   3. RHEL 8 시스템에서 다음 명령을 실행하여 교환 키의 지문을 생성합니다. http://tang1.example.com:7500 를 Tang 서버의 URL로 바꿉니다.

      $ clevis-encrypt-tang '{"url":"http://tang1.example.com:7500"}' < /dev/null > /dev/null 1

      1

      이 예에서 tangd.socket은 Tang 서버의 포트 7500에서 수신 대기 중입니다.

      참고

      clevis-encrypt-tang 명령은 교환 키의 지문을 생성합니다. 이 단계에서 암호화 명령에 데이터가 전달되지 않습니다. /dev/null 은 일반 텍스트 대신 입력으로 존재합니다. 이 프로세스에 필요하지 않으므로 암호화된 출력은 /dev/null에도 전송됩니다.

      출력 예

      The advertisement contains the following signing keys:
      
      PLjNyRdGw03zlRoGjQYMahSZGu9 1

      1

      교환 키의 지문입니다.

      Do you wish to trust these keys? [ynYN] 프롬프트가 표시되면 Y를 입력합니다.

   4. 선택 사항: 오프라인 Tang 프로비저닝의 경우:

      1. curl 명령을 사용하여 서버에서 광고를 가져옵니다. http://tang2.example.com:7500 를 Tang 서버의 URL로 바꿉니다.

         $ curl -f http://tang2.example.com:7500/adv > adv.jws && cat adv.jws

         예상 출력

         {"payload": "eyJrZXlzIjogW3siYWxnIjogIkV", "protected": "eyJhbGciOiJFUzUxMiIsImN0eSI", "signature": "ADLgk7fZdE3Yt4FyYsm0pHiau7Q"}

      2. 암호화를 위해 Clevis에 알림 파일을 제공합니다.

         $ clevis-encrypt-tang '{"url":"http://tang2.example.com:7500","adv":"adv.jws"}' < /dev/null > /dev/null

   5. 노드가 고정 IP 주소 지정으로 구성된 경우 coreos-installer iso customize --dest-karg-append 를 실행하거나 RHCOS 노드를 설치할 때 coreos-installer --append-karg 옵션을 사용하여 설치된 시스템의 IP 주소를 설정합니다. 네트워크에 필요한 ip= 및 기타 인수를 추가합니다.

      중요

      정적 IP를 구성하는 일부 방법은 첫 번째 부팅 후 initramfs에 영향을 미치지 않으며 Tang 암호화에서는 작동하지 않습니다. 여기에는 coreos-installer --copy-network 옵션, coreos-installer iso customize --network-keyfile 옵션, coreos-installer pxe customize --network-keyfile 옵션이 포함되어 있으며 설치 중에 라이브 ISO 또는 PXE 이미지의 커널 명령줄에 ip= 인수를 추가합니다. 잘못된 고정 IP 구성으로 노드의 두 번째 부팅이 실패합니다.

3. 설치 노드에서 설치 프로그램이 포함된 디렉터리로 변경하고 클러스터에 대한 Kubernetes 매니페스트를 생성합니다.

   $ ./openshift-install create manifests --dir <installation_directory> 1

   1

   <installation_directory>를 설치 파일을 저장하려는 디렉토리의 경로로 바꿉니다.

4. 디스크 암호화, 미러링 또는 둘 다를 구성하는 Butane 구성을 생성합니다. 예를 들어 컴퓨팅 노드의 스토리지를 구성하려면 $HOME/clusterconfig/worker-storage.bu 파일을 생성합니다.

   부팅 장치의 butane config 예

   variant: openshift
   version: 4.17.0
   metadata:
     name: worker-storage 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   boot_device:
     layout: x86_64 3
     luks: 4
       tpm2: true 5
       tang: 6
         - url: http://tang1.example.com:7500 7
           thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 8
         - url: http://tang2.example.com:7500
           thumbprint: VCJsvZFjBSIHSldw78rOrq7h2ZF
           advertisement: "{"payload": "eyJrZXlzIjogW3siYWxnIjogIkV", "protected": "eyJhbGciOiJFUzUxMiIsImN0eSI", "signature": "ADLgk7fZdE3Yt4FyYsm0pHiau7Q"}" 9
       threshold: 1 10
     mirror: 11
       devices: 12
         - /dev/sda
         - /dev/sdb
   openshift:
     fips: true 13

   1 2

   컨트롤 플레인 구성의 경우 두 위치 모두에서 worker를 master로 바꿉니다.

   3

   이 필드를 클러스터 노드의 명령어 세트 아키텍처로 설정합니다. 일부 예로는 x86_64,aarch64 또는 ppc64le 이 있습니다.

   4

   root 파일 시스템을 암호화하려면 이 섹션을 포함합니다. 자세한 내용은 "디스크 암호화 정보"를 참조하십시오.

   5

   Trusted Platform Module (TPM)을 사용하여 root 파일 시스템을 암호화하려면 이 필드를 포함합니다.

   6

   하나 이상의 Tang 서버를 사용하려면 이 섹션을 포함합니다.

   7

   Tang 서버의 URL을 지정합니다. 이 예에서 tangd.socket은 Tang 서버의 포트 7500에서 수신 대기 중입니다.

   8

   이전 단계에서 생성된 교환 키 지문을 지정합니다.

   9

   선택 사항: 오프라인 Tang 서버의 알림을 유효한 JSON 형식으로 지정합니다.

   10

   암호 해독을 수행하려면 충족해야 하는 최소 TPM v2 및 Tang 암호화 조건 수를 지정합니다. 기본값은 1 입니다. 이 항목에 대한 자세한 내용은 "암호 임계값 구성"을 참조하십시오.

   11

   부팅 디스크를 미러링하려면 이 섹션을 포함합니다. 자세한 내용은 "디스크 미러링 정보"를 참조하십시오.

   12

   RHCOS가 설치될 디스크를 포함하여 부트 디스크 미러에 포함해야 하는 모든 디스크 장치를 나열합니다.

   13

   클러스터에서 FIPS 모드를 활성화하려면 이 지시문을 포함합니다.

   중요

   클러스터의 FIPS 모드를 활성화하려면 FIPS 모드에서 작동하도록 구성된 RHEL(Red Hat Enterprise Linux) 컴퓨터에서 설치 프로그램을 실행해야 합니다. RHEL에서 FIPS 모드 구성에 대한 자세한 내용은 FIPS 모드에서 시스템 설치를 참조하십시오. 디스크 암호화 및 미러링을 모두 사용하도록 노드를 구성하는 경우 두 기능을 동일한 Butane 구성 파일에서 구성해야 합니다. FIPS 모드가 활성화된 노드에서 디스크 암호화를 구성하는 경우 별도의 매니페스트에서 FIPS 모드도 활성화된 경우에도 동일한 Butane 구성 파일에 fips 지시문을 포함해야 합니다.

5. 해당 Butane 구성 파일에서 컨트롤 플레인 또는 컴퓨팅 노드 매니페스트를 생성하여 < installation_directory>/openshift 디렉터리에 저장합니다. 예를 들어 컴퓨팅 노드에 대한 매니페스트를 생성하려면 다음 명령을 실행합니다.

   $ butane $HOME/clusterconfig/worker-storage.bu -o <installation_directory>/openshift/99-worker-storage.yaml

   디스크 암호화 또는 미러링이 필요한 각 노드 유형에 대해 이 단계를 반복합니다.

6. 나중에 매니페스트를 업데이트해야 하는 경우 Butane 구성 파일을 저장합니다.

7. 나머지 OpenShift Container Platform 설치를 계속합니다.

   작은 정보

   디스크 암호화 또는 미러링과 관련된 오류 메시지가 설치 중에 RHCOS 노드에서 콘솔 로그를 모니터링할 수 있습니다.

   중요

   추가 데이터 파티션을 구성하면 암호화가 명시적으로 요청되지 않는 한 암호화되지 않습니다.

1. 설치 호스트에서 디버그 Pod를 사용하여 클러스터 노드에 액세스합니다.

   1. 노드의 디버그 Pod를 시작합니다. 예를 들면 다음과 같습니다.

      $ oc debug node/compute-1

   2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 노드의 root 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 노드의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

      # chroot /host

      참고

      Red Hat Enterprise Linux CoreOS (RHCOS)를 실행하는 OpenShift Container Platform 클러스터 노드는 변경할 수 없으며 Operator를 통해 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

2. 부팅 디스크 암호화를 구성한 경우 활성화되어 있는지 확인합니다.

   1. 디버그 쉘에서 노드의 root 매핑 상태를 검토합니다.

      # cryptsetup status root

      출력 예

      /dev/mapper/root is active and is in use.
        type:    LUKS2 1
        cipher:  aes-xts-plain64 2
        keysize: 512 bits
        key location: keyring
        device:  /dev/sda4 3
        sector size:  512
        offset:  32768 sectors
        size:    15683456 sectors
        mode:    read/write

      1

      암호화 형식입니다. TPM v2 또는 Tang 암호화 모드가 활성화되면 RHCOS 부팅 디스크는 LUKS2 형식을 사용하여 암호화됩니다.

      2

      LUKS2 볼륨을 암호화하는 데 사용되는 암호화 알고리즘입니다. FIPS 모드가 활성화된 경우 aes-cbc-essiv:sha256 암호가 사용됩니다.

      3

      암호화된 LUKS2 볼륨을 포함하는 장치입니다. 미러링이 활성화된 경우 값은 소프트웨어 미러 장치(예: /dev/md126 )를 나타냅니다.

   2. 암호화된 장치에 바인딩된 Clevis 플러그인을 나열합니다.

      # clevis luks list -d /dev/sda4 1

      1

      이전 단계의 출력에서 device 필드에 나열된 장치를 지정합니다.

      출력 예

      1: sss '{"t":1,"pins":{"tang":[{"url":"http://tang.example.com:7500"}]}}' 1

      1

      예제 출력에서 Tang 플러그인은 /dev/sda4 장치의 Shamir's Secret Sharing (SSS) Clevis 플러그인에서 사용합니다.

3. 미러링을 구성한 경우 활성화되어 있는지 확인합니다.

   1. 디버그 쉘에서 노드의 소프트웨어 RAID 장치를 나열합니다.

      # cat /proc/mdstat

      출력 예

      Personalities : [raid1]
      md126 : active raid1 sdb3[1] sda3[0] 1
      	  393152 blocks super 1.0 [2/2] [UU]
      
      md127 : active raid1 sda4[0] sdb4[1] 2
      	  51869632 blocks super 1.2 [2/2] [UU]
      
      unused devices: <none>

      1

      /dev/md126 소프트웨어 RAID 미러 장치는 클러스터 노드에서 /dev/sda3 및 /dev/sdb3 디스크 장치를 사용합니다.

      2

      /dev/md127 소프트웨어 RAID 미러 장치는 클러스터 노드에서 /dev/sda4 및 /dev/sdb4 디스크 장치를 사용합니다.

   2. 이전 명령의 출력에 나열된 각 소프트웨어 RAID 장치의 세부 정보를 검토합니다. 다음 예제에서는 /dev/md126 장치의 세부 정보를 나열합니다.

      # mdadm --detail /dev/md126

      출력 예

      /dev/md126:
                 Version : 1.0
           Creation Time : Wed Jul  7 11:07:36 2021
              Raid Level : raid1 1
              Array Size : 393152 (383.94 MiB 402.59 MB)
           Used Dev Size : 393152 (383.94 MiB 402.59 MB)
            Raid Devices : 2
           Total Devices : 2
             Persistence : Superblock is persistent
      
             Update Time : Wed Jul  7 11:18:24 2021
                   State : clean 2
          Active Devices : 2 3
         Working Devices : 2 4
          Failed Devices : 0 5
           Spare Devices : 0
      
      Consistency Policy : resync
      
                    Name : any:md-boot 6
                    UUID : ccfa3801:c520e0b5:2bee2755:69043055
                  Events : 19
      
          Number   Major   Minor   RaidDevice State
             0     252        3        0      active sync   /dev/sda3 7
             1     252       19        1      active sync   /dev/sdb3 8

      1

      장치의 RAID 수준을 지정합니다. RAID1 은 RAID 1 디스크 미러링을 나타냅니다.

      2

      RAID 장치의 상태를 지정합니다.

      3 4

      활성 상태이고 작동 중인 기본 디스크 장치의 수를 나타냅니다.

      5

      실패 상태에 있는 기본 디스크 장치의 수를 나타냅니다.

      6

      소프트웨어 RAID 장치의 이름입니다.

      7 8

      소프트웨어 RAID 장치에서 사용하는 기본 디스크 장치에 대한 정보를 제공합니다.

   3. 소프트웨어 RAID 장치에 마운트된 파일 시스템을 나열합니다.

      # mount | grep /dev/md

      출력 예

      /dev/md127 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /etc type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /usr type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /sysroot type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/containers/storage/overlay type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/1 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/2 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/3 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/4 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/5 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
      /dev/md126 on /boot type ext4 (rw,relatime,seclabel)

      예제 출력에서 /boot 파일 시스템은 dev/md126 소프트웨어 RAID 장치에 마운트되고 root 파일 시스템은 /dev/md127에 마운트됩니다.

4. 각 OpenShift Container Platform 노드 유형에 대한 확인 단계를 반복합니다.

프로세스

1. 소프트웨어 RAID를 사용하여 데이터 볼륨을 구성하는 Butane 구성을 만듭니다.

   • 미러링된 부팅 디스크에 사용되는 것과 동일한 디스크에 RAID 1을 사용하여 데이터 볼륨을 구성하려면 $HOME/clusterconfig/raid1-storage.bu 파일을 생성합니다. 예를 들면 다음과 같습니다.

     미러링된 부팅 디스크의 RAID 1

     variant: openshift
     version: 4.17.0
     metadata:
       name: raid1-storage
       labels:
         machineconfiguration.openshift.io/role: worker
     boot_device:
       mirror:
         devices:
           - /dev/disk/by-id/scsi-3600508b400105e210000900000490000
           - /dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6
     storage:
       disks:
         - device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
           partitions:
             - label: root-1
               size_mib: 25000 1
             - label: var-1
         - device: /dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6
           partitions:
             - label: root-2
               size_mib: 25000 2
             - label: var-2
       raid:
         - name: md-var
           level: raid1
           devices:
             - /dev/disk/by-partlabel/var-1
             - /dev/disk/by-partlabel/var-2
       filesystems:
         - device: /dev/md/md-var
           path: /var
           format: xfs
           wipe_filesystem: true
           with_mount_unit: true

     1 2

     데이터 파티션을 부트 디스크에 추가할 때 최소 25000 메비 바이트가 권장됩니다. 값이 지정되지 않거나 지정된 값이 권장 최소값보다 작으면 생성되는 루트 파일 시스템의 크기가 너무 작아지고 RHCOS를 나중에 다시 설치할 때 데이터 파티션의 첫 번째 부분을 덮어 쓸 수 있습니다.

   • 보조 디스크에서 RAID 1을 사용하여 데이터 볼륨을 구성하려면 $HOME/clusterconfig/raid1-alt-storage.bu 파일을 생성합니다. 예를 들면 다음과 같습니다.

     보조 디스크에서 RAID 1

     variant: openshift
     version: 4.17.0
     metadata:
       name: raid1-alt-storage
       labels:
         machineconfiguration.openshift.io/role: worker
     storage:
       disks:
         - device: /dev/sdc
           wipe_table: true
           partitions:
             - label: data-1
         - device: /dev/sdd
           wipe_table: true
           partitions:
             - label: data-2
       raid:
         - name: md-var-lib-containers
           level: raid1
           devices:
             - /dev/disk/by-partlabel/data-1
             - /dev/disk/by-partlabel/data-2
       filesystems:
         - device: /dev/md/md-var-lib-containers
           path: /var/lib/containers
           format: xfs
           wipe_filesystem: true
           with_mount_unit: true

2. 이전 단계에서 생성한 Butane 구성에서 RAID 매니페스트를 생성하여 < installation_directory>/openshift 디렉터리에 저장합니다. 예를 들어 컴퓨팅 노드에 대한 매니페스트를 생성하려면 다음 명령을 실행합니다.

   $ butane $HOME/clusterconfig/<butane_config>.bu -o <installation_directory>/openshift/<manifest_name>.yaml 1

   1

   &lt ;butane_config > 및 < manifest_name >을 이전 단계의 파일 이름으로 바꿉니다. 예를 들어 보조 디스크의 경우 raid1-alt-storage.bu 및 raid1-alt-storage.yaml입니다.

3. 나중에 매니페스트를 업데이트해야 하는 경우 Butane config를 저장합니다.
4. 나머지 OpenShift Container Platform 설치를 계속합니다.

프로세스

1. 다음 명령을 실행하여 Intel® Matrix Storage Manager(IMSM) RAID 컨테이너를 생성합니다.

   $ mdadm -CR /dev/md/imsm0 -e \
     imsm -n2 /dev/nvme0n1 /dev/nvme1n1 1

   1

   RAID 장치 이름입니다. 이 예제에는 두 개의 장치가 나열되어 있습니다. 두 개 이상의 장치 이름을 제공하는 경우 -n 플래그를 조정해야 합니다. 예를 들어 세 개의 장치를 나열하면 -n3 플래그가 사용됩니다.

2. 컨테이너 내부에 RAID1 스토리지를 생성합니다.

   1. 다음 명령을 실행하여 실제 RAID1 볼륨 앞에 더미 RAID0 볼륨을 생성합니다.

      $ mdadm -CR /dev/md/dummy -l0 -n2 /dev/imsm0 -z10M --assume-clean

   2. 다음 명령을 실행하여 실제 RAID1 배열을 생성합니다.

      $ mdadm -CR /dev/md/coreos -l1 -n2 /dev/imsm0

   3. 다음 명령을 사용하여 RAID0 및 RAID1 멤버 배열을 중지하고 dummy RAID0 배열을 삭제합니다.

      $ mdadm -S /dev/md/dummy \
        mdadm -S /dev/md/coreos \
        mdadm --kill-subarray=0 /dev/md/imsm0

   4. 다음 명령을 실행하여 RAID1 배열을 다시 시작합니다.

      $ mdadm -A /dev/md/coreos /dev/md/imsm0

3. RAID1 장치에 RHCOS를 설치합니다.

   1. 다음 명령을 실행하여 IMSM 컨테이너의 UUID를 가져옵니다.

      $ mdadm --detail --export /dev/md/imsm0

   2. 다음 명령을 실행하여 RHCOS를 설치하고 rd.md.uuid 커널 인수를 포함합니다.

      $ coreos-installer install /dev/md/coreos \
        --append-karg rd.md.uuid=<md_UUID> 1
        ...

      1

      IMSM 컨테이너의 UUID입니다.

      RHCOS를 설치하는 데 필요한 추가 coreos-installer 인수를 포함합니다.