3.6. IBM Z 및 IBM LinuxONE에서 z/VM을 사용하여 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성


IBM Z® 및 IBM® LinuxONE(s390x)에서 z/VM이 있는 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 기존 단일 아키텍처 x86_64 클러스터가 있어야 합니다. 그런 다음 s390x 컴퓨팅 머신을 OpenShift Container Platform 클러스터에 추가할 수 있습니다.

s390x 노드를 클러스터에 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다음 절차에서는 z/VM 인스턴스를 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 s390x 노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.

x86_64 에서 다중 아키텍처 컴퓨팅 머신이 있는 IBM Z® 또는 IBM® LinuxONE(s390x) 클러스터를 생성하려면 IBM Z® 및 IBM® LinuxONE에 클러스터 설치 지침을 따르십시오. 그런 다음 베어 메탈, IBM Power 또는 IBM Z에서 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성에 설명된 대로 x86_64 컴퓨팅 머신을 추가할 수 있습니다.

참고

보조 아키텍처 노드를 클러스터에 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 오브젝트를 배포하는 것이 좋습니다. 자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

3.6.1. 클러스터 호환성 확인

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. OpenShift CLI(oc)에 로그인합니다.
  2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다.

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다.

    {
     "url": "https://access.redhat.com/errata/<errata_version>"
    }
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

3.6.2. z/VM을 사용하여 IBM Z에서 RHCOS 머신 생성

IBM Z® with z/VM에서 실행되는 추가 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 기존 클러스터에 연결할 수 있습니다.

사전 요구 사항

  • 노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain Name Server)가 있습니다.
  • 생성한 머신에 액세스할 수 있는 프로비저닝 머신에서 HTTP 또는 HTTPS 서버가 실행되고 있습니다.

프로세스

  1. UDP 집계를 비활성화합니다.

    현재 UDP 집계는 IBM Z®에서 지원되지 않으며 x86_64 컨트롤 플레인 및 추가 s390x 컴퓨팅 머신이 있는 다중 아키텍처 컴퓨팅 클러스터에서 자동으로 비활성화되지 않습니다. 추가 컴퓨팅 노드가 클러스터에 올바르게 추가되도록 하려면 UDP 집계를 수동으로 비활성화해야 합니다.

    1. 다음 콘텐츠를 사용하여 YAML 파일 udp-aggregation-config.yaml 을 생성합니다.

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator
    2. 다음 명령을 실행하여 ConfigMap 리소스를 생성합니다.

      $ oc create -f udp-aggregation-config.yaml
  2. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  3. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.
  4. Ignition 파일이 URL에서 사용 가능한지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

    $ curl -k http://<http_server>/worker.ign
  5. 다음 명령을 실행하여 RHEL 라이브 커널,initramfs, rootfs 파일을 다운로드합니다.

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
    | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
  6. 다운로드한 RHEL 라이브 커널,initramfsrootfs 파일을 추가하려는 z/VM 게스트에서 액세스할 수 있는 HTTP 또는 HTTPS 서버로 이동합니다.
  7. z/VM 게스트에 대한 매개변수 파일을 생성합니다. 다음 매개변수는 가상 머신에 고유합니다.

    • 선택 사항: 고정 IP 주소를 지정하려면 각각 콜론으로 구분된 다음 항목이 포함된 ip= 매개변수를 추가합니다.

      1. 컴퓨터의 IP 주소
      2. 빈 문자열
      3. 게이트웨이
      4. 넷 마스크
      5. hostname.domainname 형식의 시스템 호스트 및 도메인 이름. RHCOS가 설정하도록 하려면 이 값을 생략하십시오.
      6. 네트워크 인터페이스 이름. RHCOS가 설정하도록 하려면 이 값을 생략하십시오.
      7. 값이 없음입니다.
    • coreos.inst.ignition_url= 의 경우 worker.ign 파일의 URL을 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
    • coreos.live.rootfs_url= 의 경우 부팅 중인 커널initramfs 와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
    • DASD 유형 디스크에 설치하려면 다음 작업을 완료합니다.

      1. coreos.inst.install_dev= 의 경우 /dev/dasda 를 지정합니다.
      2. rd.dasd=의 경우 RHCOS를 설치할 DASD를 지정합니다.
      3. 필요한 경우 추가 매개변수를 조정할 수 있습니다.

        다음은 추가-worker-dasd.parm 매개변수 파일 예제입니다.

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        rd.dasd=0.0.3490 \
        zfcp.allow_lun_scan=0

        매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

    • FCP 유형 디스크에 설치하려면 다음 작업을 완료합니다.

      1. RHCOS를 설치할 FCP 디스크를 지정하려면 rd.zfcp=<adapter>,<wwpn>,<lun>을 사용합니다. 다중 경로의 경우 추가 경로마다 이 단계를 반복합니다.

        참고

        여러 경로를 사용하여 설치할 때 나중에 문제가 발생할 수 있으므로 설치 후에 직접 멀티패스를 활성화해야 합니다.

      2. 설치 장치를 coreos.inst.install_dev=/dev/sda 로 설정합니다.

        참고

        NPIV로 추가 LUN을 구성하는 경우 FCP에는 zfcp.allow_lun_scan=0이 필요합니다. 예를 들어 CSI 드라이버를 사용하므로 zfcp.allow_lun_scan=1 을 활성화해야 하는 경우, 각 노드가 다른 노드의 부팅 파티션에 액세스할 수 없도록 NPIV를 구성해야 합니다.

      3. 필요한 경우 추가 매개변수를 조정할 수 있습니다.

        중요

        멀티패스를 완전히 활성화하려면 추가 설치 후 단계가 필요합니다. 자세한 내용은 설치 후 머신 구성 작업 의 "RHCOS에서 커널 인수를 사용하여 멀티패스 활성화"를 참조하십시오.

        다음은 다중 경로가 있는 작업자 노드의 additional-worker-fcp.parm 매개변수 파일 예제입니다.

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

  8. FTP를 사용하여 initramfs,커널, 매개 변수 파일 및 RHCOS 이미지를 z/VM으로 전송합니다. FTP를 사용하여 파일을 전송하고 가상 리더에서 부팅하는 방법에 대한 자세한 내용은 Z/VM에서 설치를 참조하십시오.
  9. z/VM 게스트 가상 머신의 가상 리더에 파일을 punch합니다.

    IBM® 문서의 PUNCH 를 참조하십시오.

    작은 정보

    CP PUNCH 명령을 사용하거나 Linux를 사용하는 경우 vmur 명령을 사용하여 두 개의 z/VM 게스트 가상 머신간에 파일을 전송할 수 있습니다.

  10. 부트스트랩 시스템에서 CMS에 로그인합니다.
  11. 다음 명령을 실행하여 리더의 부트스트랩 시스템을 IPL합니다.

    $ ipl c

    IBM® 문서의 IPL 을 참조하십시오.

3.6.3. 시스템의 인증서 서명 요청 승인

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

  1. 클러스터가 시스템을 인식하는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.30.3
    master-1  Ready     master  63m  v1.30.3
    master-2  Ready     master  64m  v1.30.3

    출력에 생성된 모든 시스템이 나열됩니다.

    참고

    이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.

  2. 보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해 Pending 또는 Approved 상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.

    $ oc get csr

    출력 예

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.

  3. CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이 Pending 상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.

    참고

    CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 클라이언트 CSR이 승인되면 Kubelet은 인증서에 대한 보조 CSR을 생성하므로 수동 승인이 필요합니다. 그러면 Kubelet에서 동일한 매개변수를 사용하여 새 인증서를 요청하는 경우 인증서 갱신 요청은 machine-approver에 의해 자동으로 승인됩니다.

    참고

    베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로 oc exec, oc rsh, oc logs 명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이 system:node 또는 system:admin 그룹의 node-bootstrapper 서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.

    • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
    • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      참고

      일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.

  4. 이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.

    $ oc get csr

    출력 예

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...

  5. 나머지 CSR이 승인되지 않고 Pending 상태인 경우 클러스터 머신의 CSR을 승인합니다.

    • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
    • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  6. 모든 클라이언트 및 서버 CSR이 승인된 후 머신은 Ready 상태가 됩니다. 다음 명령을 실행하여 확인합니다.

    $ oc get nodes

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.30.3
    master-1  Ready     master  73m  v1.30.3
    master-2  Ready     master  74m  v1.30.3
    worker-0  Ready     worker  11m  v1.30.3
    worker-1  Ready     worker  11m  v1.30.3

    참고

    머신이 Ready 상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.