SupportConsoleDéveloppeursCommencer un essaiContact

21.7. Valider le réglage d'un cluster OpenShift à nœud unique pour les charges de travail des applications vDU

Avant de pouvoir déployer des applications d'unités virtuelles distribuées (vDU), vous devez régler et configurer le microprogramme de l'hôte du cluster et divers autres paramètres de configuration du cluster. Utilisez les informations suivantes pour valider la configuration de la grappe afin de prendre en charge les charges de travail vDU.

Ressources supplémentaires

21.7.1. Configuration recommandée du micrologiciel pour les hôtes de la grappe vDU

Utilisez le tableau suivant comme base pour configurer le firmware de l'hôte du cluster pour les applications vDU fonctionnant sur OpenShift Container Platform 4.12.

Note

Le tableau suivant est une recommandation générale pour la configuration du micrologiciel de l'hôte du cluster vDU. Les paramètres exacts du micrologiciel dépendront de vos besoins et de votre plate-forme matérielle spécifique. La configuration automatique du firmware n'est pas gérée par le pipeline de provisionnement zero touch.

Tableau 21.7. Paramètres recommandés pour le micrologiciel de l'hôte de la grappe
Réglage du micrologicielConfigurationDescription

HyperTransport (HT)

Activé

Le bus HyperTransport (HT) est une technologie de bus développée par AMD. HT fournit un lien à grande vitesse entre les composants de la mémoire hôte et les autres périphériques du système.

UEFI

Activé

Activer le démarrage à partir de l'UEFI pour l'hôte vDU.

Politique de puissance et de performance de l'unité centrale

Performances

Définissez la politique de puissance et de performance de l'unité centrale pour optimiser le système en termes de performance plutôt que d'efficacité énergétique.

Mise à l'échelle de la fréquence Uncore

Handicapés

Désactivez l'option Uncore Frequency Scaling pour éviter que la tension et la fréquence des parties non centrales de l'unité centrale ne soient réglées indépendamment.

Fréquence Uncore

Maximum

Règle les parties non essentielles de l'unité centrale, telles que le cache et le contrôleur de mémoire, à leur fréquence de fonctionnement maximale possible.

Performance Limite P

Handicapés

Désactiver la limite de performance P pour empêcher la coordination de la fréquence Uncore des processeurs.

Technologie Intel® SpeedStep améliorée

Activé

Activez Enhanced Intel SpeedStep pour permettre au système d'ajuster dynamiquement la tension du processeur et la fréquence du cœur, ce qui réduit la consommation d'énergie et la production de chaleur dans l'hôte.

Technologie Intel® Turbo Boost

Activé

Activez la technologie Turbo Boost pour les processeurs basés sur Intel afin d'autoriser automatiquement les cœurs du processeur à fonctionner plus rapidement que la fréquence de fonctionnement nominale s'ils fonctionnent en dessous des limites de puissance, de courant et de température spécifiées.

TDP configurable par Intel

Activé

Active la puissance de conception thermique (TDP) pour le CPU.

Niveau TDP configurable

Niveau 2

Le niveau TDP définit la consommation d'énergie de l'unité centrale requise pour une performance donnée. Le niveau TDP 2 permet au CPU d'atteindre le niveau de performance le plus stable au prix de la consommation d'énergie.

Turbo à haut rendement énergétique

Handicapés

Désactiver le Turbo écoénergétique pour empêcher le processeur d'utiliser une stratégie basée sur l'efficacité énergétique.

Matériel P-States

Activé ou désactivé

Activer les états P contrôlés par le système d'exploitation pour permettre des configurations d'économie d'énergie. Désactiver P-states (états de performance) pour optimiser le système d'exploitation et le processeur en termes de performance plutôt que de consommation d'énergie.

Paquet C-State

État C0/C1

Utilisez les états C0 ou C1 pour mettre le processeur dans un état totalement actif (C0) ou pour arrêter les horloges internes du processeur fonctionnant dans le logiciel (C1).

C1E

Handicapés

CPU Enhanced Halt (C1E) est une fonction d'économie d'énergie des puces Intel. La désactivation de C1E empêche le système d'exploitation d'envoyer une commande d'arrêt au processeur lorsqu'il est inactif.

Processeur C6

Handicapés

L'économie d'énergie C6 est une fonction du processeur qui désactive automatiquement les cœurs et la mémoire cache inactifs du processeur. La désactivation de C6 améliore les performances du système.

Regroupement sous-NUMA

Handicapés

Le clustering Sub-NUMA divise les cœurs de processeur, le cache et la mémoire en plusieurs domaines NUMA. La désactivation de cette option peut améliorer les performances des charges de travail sensibles à la latence.

Note

Activer les paramètres SR-IOV et VT-d globaux dans le micrologiciel de l'hôte. Ces paramètres sont pertinents pour les environnements bare-metal.

Note

Activez à la fois C-states et P-States contrôlé par le système d'exploitation pour permettre une gestion de l'alimentation par pod.

21.7.2. Configurations de cluster recommandées pour l'exécution des applications vDU

Les clusters qui exécutent des applications d'unités distribuées virtualisées (vDU) nécessitent une configuration hautement réglée et optimisée. Les informations suivantes décrivent les différents éléments nécessaires à la prise en charge des charges de travail vDU dans les clusters OpenShift Container Platform 4.12.

21.7.2.4. Vérification de la version du noyau temps réel

Utilisez toujours la dernière version du noyau temps réel dans vos clusters OpenShift Container Platform. Si vous n'êtes pas sûr de la version du noyau utilisée dans le cluster, vous pouvez comparer la version actuelle du noyau en temps réel à la version release à l'aide de la procédure suivante.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté en tant qu'utilisateur avec des privilèges cluster-admin.
  • Vous avez installé podman.

Procédure

  1. Exécutez la commande suivante pour obtenir la version du cluster : 

    $ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')

  2. Obtenir le numéro SHA de l'image de la version : 

    $ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)

  3. Exécutez le conteneur d'image de version et extrayez la version du noyau qui est fournie avec la version actuelle du cluster : 

    $ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'

    Exemple de sortie

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

    Il s'agit de la version par défaut du noyau en temps réel qui est livrée avec la version.

    Note

    Le noyau temps réel est désigné par la chaîne .rt dans la version du noyau.

Vérification

Vérifiez que la version du noyau indiquée pour la version actuelle de la grappe correspond au noyau en temps réel qui s'exécute dans la grappe. Exécutez les commandes suivantes pour vérifier la version du noyau en temps réel en cours d'exécution :

  1. Ouvrez une connexion shell à distance au nœud de cluster : 

    oc debug node/<node_name>

  2. Vérifier la version du noyau temps réel : 

    sh-4.4# uname -r

    Exemple de sortie

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

21.7.3. Vérification de l'application des configurations recommandées pour les clusters

Vous pouvez vérifier que les clusters exécutent la bonne configuration. La procédure suivante décrit comment vérifier les différentes configurations requises pour déployer une application DU dans les clusters OpenShift Container Platform 4.12.

Conditions préalables

  • Vous avez déployé un cluster et l'avez optimisé pour les charges de travail vDU.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté en tant qu'utilisateur avec les privilèges cluster-admin.

Procédure

  1. Vérifiez que les sources OperatorHub par défaut sont désactivées. Exécutez la commande suivante : 

    $ oc get operatorhub cluster -o yaml

    Exemple de sortie

    spec:
    disableAllDefaultSources: true

  2. Vérifiez que toutes les ressources CatalogSource requises sont annotées pour le partitionnement de la charge de travail (PreferredDuringScheduling) en exécutant la commande suivante : 

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

    Exemple de sortie

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

    1
    CatalogSource les ressources qui ne sont pas annotées sont également renvoyées. Dans cet exemple, la ressource ran-operators CatalogSource n'est pas annotée et n'a pas l'annotation PreferredDuringScheduling.
    Note

    Dans un cluster vDU correctement configuré, une seule source de catalogue annotée est répertoriée.

  3. Vérifiez que tous les espaces de noms d'opérateurs OpenShift Container Platform applicables sont annotés pour le partitionnement de la charge de travail. Cela inclut tous les opérateurs installés avec le noyau d'OpenShift Container Platform et l'ensemble des opérateurs supplémentaires inclus dans la configuration de réglage DU de référence. Exécutez la commande suivante : 

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

    Exemple de sortie

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

    Important

    Les opérateurs supplémentaires ne doivent pas être annotés pour le partitionnement de la charge de travail. Dans la sortie de la commande précédente, les opérateurs supplémentaires doivent être listés sans aucune valeur à droite du séparateur --.

  4. Vérifiez que la configuration de ClusterLogging est correcte. Exécutez les commandes suivantes :

    1. Validez que les journaux d'entrée et de sortie appropriés sont configurés : 

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

      Exemple de sortie

      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. Vérifiez que le calendrier de curation est adapté à votre application : 

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

      Exemple de sortie

      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. Vérifiez que la console web est désactivée (managementState: Removed) en exécutant la commande suivante : 

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

    Exemple de sortie

    Supprimé

  6. Vérifiez que chronyd est désactivé sur le nœud de cluster en exécutant les commandes suivantes : 

    oc debug node/<node_name>

    Vérifiez l'état de chronyd sur le nœud : 

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

    Exemple de sortie

    ● 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. Vérifiez que l'interface PTP est bien synchronisée avec l'horloge primaire en utilisant une connexion shell à distance au conteneur linuxptp-daemon et à l'outil PTP Management Client (pmc) :

    1. Définissez la variable $PTP_POD_NAME avec le nom du module linuxptp-daemon en exécutant la commande suivante : 

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

    2. Exécutez la commande suivante pour vérifier l'état de synchronisation du dispositif 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'

      Exemple de sortie

      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. Exécutez la commande suivante pmc pour vérifier l'état de l'horloge 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'

      Exemple de sortie

      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 doit se situer entre -100 et 100 ns.
      2
      Indique que l'horloge PTP est synchronisée avec un maître et que l'horloge locale n'est pas l'horloge du grand maître.

    4. Vérifiez que la valeur attendue de master offset correspondant à la valeur de /var/run/ptp4l.0.config se trouve dans le journal de linuxptp-daemon-container: 

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

      Exemple de sortie

      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. Vérifiez que la configuration du SR-IOV est correcte en exécutant les commandes suivantes :

    1. Vérifiez que la valeur disableDrain de la ressource SriovOperatorConfig est définie sur true: 

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

      Exemple de sortie

      true

    2. Vérifiez que l'état de synchronisation de SriovNetworkNodeState est Succeeded en exécutant la commande suivante : 

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

      Exemple de sortie

      Succeeded

    3. Vérifier que le nombre et la configuration attendus des fonctions virtuelles (Vfs) sous chaque interface configurée pour SR-IOV sont présents et corrects dans le champ .status.interfaces. Par exemple : 

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

      Exemple de sortie

      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. Vérifiez que le profil de performance du cluster est correct. Les sections cpu et hugepages varient en fonction de votre configuration matérielle. Exécutez la commande suivante : 

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

    Exemple de sortie

    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

    Note

    Les paramètres du processeur dépendent du nombre de cœurs disponibles sur le serveur et doivent être alignés sur les paramètres de partitionnement de la charge de travail. La configuration de hugepages dépend du serveur et de l'application.

  10. Vérifiez que le site PerformanceProfile a été appliqué avec succès au cluster en exécutant la commande suivante : 

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

    Exemple de sortie

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

  11. Vérifiez les paramètres du correctif de performance Tuned en exécutant la commande suivante : 

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

    Exemple de sortie

    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
    La liste des processeurs dans cmdline=nohz_full= variera en fonction de votre configuration matérielle.

  12. Vérifiez que les diagnostics de mise en réseau du cluster sont désactivés en exécutant la commande suivante : 

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

    Exemple de sortie

    true

  13. Vérifiez que l'intervalle de maintenance de Kubelet est réglé sur un taux plus lent. Ce paramètre est défini dans la configuration de la machine containerMountNS. Exécutez la commande suivante : 

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

    Exemple de sortie

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

  14. Vérifiez que Grafana et alertManagerMain sont désactivés et que la période de rétention de Prometheus est fixée à 24 heures en exécutant la commande suivante : 

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

    Exemple de sortie

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

    1. Utilisez les commandes suivantes pour vérifier que les routes Grafana et alertManagerMain ne sont pas trouvées dans le cluster : 

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

      Les deux requêtes devraient renvoyer des messages à l'adresse Error from server (NotFound).

  15. Vérifiez qu'il y a un minimum de 4 CPUs alloués comme reserved pour chacun des arguments de ligne de commande PerformanceProfile, Tuned performance-patch, workload partitioning, et kernel en exécutant la commande suivante : 

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

    Exemple de sortie

    0-3

    Note

    En fonction de votre charge de travail, vous pouvez avoir besoin d'allouer des unités centrales réservées supplémentaires.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.