サポートコンソール開発者トライアルの開始お問い合わせ

7.3. 推奨されるクラスター設定が適用されていることの確認

クラスターが正しい設定で実行されていることを確認できます。以下の手順では、DU アプリケーションを OpenShift Container Platform 4.16 クラスターにデプロイするために必要なさまざまな設定を確認する方法を説明します。

前提条件

  • クラスターをデプロイし、vDU ワークロード用に調整している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. デフォルトの OperatorHub ソースが無効になっていることを確認します。以下のコマンドを実行します。 

    $ oc get operatorhub cluster -o yaml

    出力例

    spec:
    disableAllDefaultSources: true

  2. 次のコマンドを実行して、必要なすべての CatalogSource リソースにワークロードのパーティショニング (PreferredDuringScheduling) のアノテーションが付けられていることを確認します。 

    $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

    出力例

    certified-operators -- {"effect": "PreferredDuringScheduling"}
community-operators -- {"effect": "PreferredDuringScheduling"}
ran-operators 1
redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
redhat-operators -- {"effect": "PreferredDuringScheduling"}

    1
    アノテーションが付けられていない CatalogSource リソースも返されます。この例では、ran-operators CatalogSource リソースにはアノテーションが付けられておらず、PreferredDuringScheduling アノテーションがありません。
    注記

    適切に設定された vDU クラスターでは、単一のアノテーション付きカタログソースのみがリスト表示されます。

  3. 該当するすべての OpenShift Container Platform Operator の namespace がワークロードのパーティショニング用にアノテーションされていることを確認します。これには、コア OpenShift Container Platform とともにインストールされたすべての Operator と、参照 DU チューニング設定に含まれる追加の Operator のセットが含まれます。以下のコマンドを実行します。 

    $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

    出力例

    default --
openshift-apiserver -- management
openshift-apiserver-operator -- management
openshift-authentication -- management
openshift-authentication-operator -- management

    重要

    追加の Operator は、ワークロードパーティショニングのためにアノテーションを付けてはなりません。前のコマンドからの出力では、追加の Operator が -- セパレーターの右側に値なしでリストされている必要があります。

  4. ClusterLogging 設定が正しいことを確認してください。以下のコマンドを実行します。

    1. 適切な入力ログと出力ログが設定されていることを確認します。 

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  creationTimestamp: "2022-07-19T21:51:41Z"
  generation: 1
  name: instance
  namespace: openshift-logging
  resourceVersion: "1030342"
  uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
spec:
  inputs:
  - infrastructure: {}
    name: infra-logs
  outputs:
  - name: kafka-open
    type: kafka
    url: tcp://10.46.55.190:9092/test
  pipelines:
  - inputRefs:
    - audit
    name: audit-logs
    outputRefs:
    - kafka-open
  - inputRefs:
    - infrastructure
    name: infrastructure-logs
    outputRefs:
    - kafka-open
...

    2. キュレーションスケジュールがアプリケーションに適していることを確認します。 

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  creationTimestamp: "2022-07-07T18:22:56Z"
  generation: 1
  name: instance
  namespace: openshift-logging
  resourceVersion: "235796"
  uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
spec:
  collection:
    logs:
      fluentd: {}
      type: fluentd
  curation:
    curator:
      schedule: 30 3 * * *
    type: curator
  managementState: Managed
...

  5. 次のコマンドを実行して、Web コンソールが無効になっている (managementState: Removed) ことを確認します。 

    $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

    出力例

    Removed

  6. 次のコマンドを実行して、クラスターノードで chronyd が無効になっていることを確認します。 

    $ oc debug node/<node_name>

    ノードで chronyd のステータスを確認します。 

    sh-4.4# chroot /host
    sh-4.4# systemctl status chronyd

    出力例

    ● chronyd.service - NTP client/server
    Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
    Active: inactive (dead)
      Docs: man:chronyd(8)
            man:chrony.conf(5)

  7. linuxptp-daemon コンテナーへのリモートシェル接続と PTP Management Client (pmc) ツールを使用して、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。

    1. 次のコマンドを実行して、$PTP_POD_NAME 変数に linuxptp-daemon Pod の名前を設定します。 

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

    2. 次のコマンドを実行して、PTP デバイスの同期ステータスを確認します。 

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      出力例

      sending: GET PORT_DATA_SET
  3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
    portIdentity            3cecef.fffe.7a7020-1
    portState               SLAVE
    logMinDelayReqInterval  -4
    peerMeanPathDelay       0
    logAnnounceInterval     1
    announceReceiptTimeout  3
    logSyncInterval         0
    delayMechanism          1
    logMinPdelayReqInterval 0
    versionNumber           2
  3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
    portIdentity            3cecef.fffe.7a7020-2
    portState               LISTENING
    logMinDelayReqInterval  0
    peerMeanPathDelay       0
    logAnnounceInterval     1
    announceReceiptTimeout  3
    logSyncInterval         0
    delayMechanism          1
    logMinPdelayReqInterval 0
    versionNumber           2

    3. 次の pmc コマンドを実行して、PTP クロックのステータスを確認します。 

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      出力例

      sending: GET TIME_STATUS_NP
  3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
    master_offset              10 1
    ingress_time               1657275432697400530
    cumulativeScaledRateOffset +0.000000000
    scaledLastGmPhaseChange    0
    gmTimeBaseIndicator        0
    lastGmPhaseChange          0x0000'0000000000000000.0000
    gmPresent                  true 2
    gmIdentity                 3c2c30.ffff.670e00

      1
      master_offset は -100 から 100 ns の間である必要があります。
      2
      PTP クロックがマスターに同期されており、ローカルクロックがグランドマスタークロックではないことを示します。

    4. /var/run/ptp4l.0.config の値に対応する予期される master offset 値が linuxptp-daemon-container ログにあることを確認します。 

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      出力例

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

  8. 次のコマンドを実行して、SR-IOV 設定が正しいことを確認します。

    1. SriovOperatorConfig リソースの disableDrain 値が true に設定されていることを確認します。 

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      出力例

      true

    2. 次のコマンドを実行して、SriovNetworkNodeState 同期ステータスが Succeeded であることを確認します。 

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      出力例

      Succeeded

    3. SR-IOV 用に設定された各インターフェイスの下の仮想機能 (Vfs) の予想される数と設定が、.status.interfaces フィールドに存在し、正しいことを確認します。以下に例を示します。 

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      出力例

      apiVersion: v1
items:
- apiVersion: sriovnetwork.openshift.io/v1
  kind: SriovNetworkNodeState
...
  status:
    interfaces:
    ...
    - Vfs:
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.0
        vendor: "8086"
        vfID: 0
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.1
        vendor: "8086"
        vfID: 1
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.2
        vendor: "8086"
        vfID: 2
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.3
        vendor: "8086"
        vfID: 3
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.4
        vendor: "8086"
        vfID: 4
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.5
        vendor: "8086"
        vfID: 5
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.6
        vendor: "8086"
        vfID: 6
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.7
        vendor: "8086"
        vfID: 7

  9. クラスターパフォーマンスプロファイルが正しいことを確認します。cpu セクションと hugepages セクションは、ハードウェア設定によって異なります。以下のコマンドを実行します。 

    $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

    出力例

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  creationTimestamp: "2022-07-19T21:51:31Z"
  finalizers:
  - foreground-deletion
  generation: 1
  name: openshift-node-performance-profile
  resourceVersion: "33558"
  uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
spec:
  additionalKernelArgs:
  - idle=poll
  - rcupdate.rcu_normal_after_boot=0
  - efi=runtime
  cpu:
    isolated: 2-51,54-103
    reserved: 0-1,52-53
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 32
      size: 1G
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/master: ""
  net:
    userLevelNetworking: true
  nodeSelector:
    node-role.kubernetes.io/master: ""
  numa:
    topologyPolicy: restricted
  realTimeKernel:
    enabled: true
status:
  conditions:
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "True"
    type: Available
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "True"
    type: Upgradeable
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "False"
    type: Progressing
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "False"
    type: Degraded
  runtimeClass: performance-openshift-node-performance-profile
  tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

    注記

    CPU 設定は、サーバーで使用可能なコアの数に依存し、ワークロードパーティショニングの設定に合わせる必要があります。hugepages の設定は、サーバーとアプリケーションに依存します。

  10. 次のコマンドを実行して、PerformanceProfile がクラスターに正常に適用されたことを確認します。 

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    出力例

    Available -- True
Upgradeable -- True
Progressing -- False
Degraded -- False

  11. 次のコマンドを実行して、Tuned パフォーマンスパッチの設定を確認します。 

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    出力例

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  creationTimestamp: "2022-07-18T10:33:52Z"
  generation: 1
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  resourceVersion: "34024"
  uid: f9799811-f744-4179-bf00-32d4436c08fd
spec:
  profile:
  - data: |
      [main]
      summary=Configuration changes profile inherited from performance created tuned
      include=openshift-node-performance-openshift-node-performance-profile
      [bootloader]
      cmdline_crash=nohz_full=2-23,26-47 1
      [sysctl]
      kernel.timer_migration=1
      [scheduler]
      group.ice-ptp=0:f:10:*:ice-ptp.*
      [service]
      service.stalld=start,enable
      service.chronyd=stop,disable
    name: performance-patch
  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: master
    priority: 19
    profile: performance-patch

    1
    cmdline=nohz_full= の cpu リストは、ハードウェア設定によって異なります。

  12. 次のコマンドを実行して、クラスターネットワーク診断が無効になっていることを確認します。 

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    出力例

    true

  13. Kubelet のハウスキーピング間隔が、遅い速度に調整されていることを確認します。これは、containerMountNS マシン設定で設定されます。以下のコマンドを実行します。 

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    出力例

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

  14. 次のコマンドを実行して、Grafana と alertManagerMain が無効になっていること、および Prometheus の保持期間が 24 時間に設定されていることを確認します。 

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    出力例

    grafana:
  enabled: false
alertmanagerMain:
  enabled: false
prometheusK8s:
   retention: 24h

    1. 次のコマンドを使用して、Grafana および alertManagerMain ルートがクラスター内に見つからないことを確認します。 

      $ oc get route -n openshift-monitoring alertmanager-main
      $ oc get route -n openshift-monitoring grafana

      どちらのクエリーも Error from server (NotFound) メッセージを返す必要があります。

  15. 次のコマンドを実行して、PerformanceProfile、Tuned performance-patch、ワークロードパーティショニング、およびカーネルコマンドライン引数のそれぞれに reserved として割り当てられた CPU が少なくとも 4 つあることを確認します。 

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    出力例

    0-3

    注記

    ワークロードの要件によっては、追加の予約済み CPU の割り当てが必要になる場合があります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.