Mises à niveau de Serveur MID

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 15 minutes de lecture

    • Mettez à niveau les MID Servers manuellement ou automatiquement via l’instance. La mise à niveau automatique du serveur MID est déclenchée lorsque l’instance est mise à niveau et que le serveur MID n’a plus la même version. Le nouveau package de Serveur MID est téléchargé à partir de install.service-now.com, remplace l’ancien et le Serveur MID démarre avec la nouvelle version.

    Avertissement :
    Le Serveur MID ne peut pas effectuer la mise à niveau automatique sur un hôte Windows si le service Expérience d’application Windows est désactivé. Pour plus d’informations sur l’erreur qui s’affiche et pour obtenir des instructions sur la réactivation de ce service, reportez-vous à la section KB0597552.

    Besoins de mise à niveau du Serveur MID

    Accès au site de téléchargement du Serveur MID
    L’ordinateur hôte du Serveur MID doit avoir accès au site de téléchargement ServiceNow au install.service-now.com pour effectuer automatiquement la mise à niveau. Si vous disposez d’un environnement ServiceNow auto-hébergé qui bloque l’accès au site de téléchargement, vous devez importer manuellement le package d’installation du Serveur MID dans vos hôtes du Serveur MID. Pour obtenir des instructions, consultez KB0760123 dans la base de connaissances auto-hébergée.
    L’accès du MID Server à OCSP est bloqué
    Les pare-feu et les configurations de proxy peuvent bloquer les appels vers le serveur OCSP Entrust, empêchant ainsi le MID Server de fonctionner. Vous devrez peut-être modifier vos autorisations de pare-feu afin que le trafic OCSP passe correctement. Pour plus d’informations et de résolutions, consultez l’article de la base de connaissances HI [KB1216223].
    Compatibilité du système d’exploitation du Serveur MID
    La mise à niveau des serveurs MID Windows ou Linux avec des systèmes d’exploitation 32 bits n’est pas prise en charge. Pour plus d’informations, consultez [KB0863694].

    Le Serveur MID ne peut pas effectuer la mise à niveau sur un hôte Windows si le service Expérience d’application Windows est désactivé. Pour plus d’informations sur l’erreur qui s’affiche et pour obtenir des instructions sur la réactivation de ce service, reportez-vous à la section KB0597552.

    La mise à niveau du MID Server est bloquée par certains antivirus fonctionnant sur les hôtes Windows. Pour plus d’informations sur les erreurs et la liste de ces antivirus, consultez KB0870329.

    Toute mise à niveau de Serveur MID Linux dont le service est installé sous le système dans Madrid ou une version antérieure doit réinstaller le service après la mise à niveau. Si vous n’avez pas réinstallé manuellement le service lors des mises à niveau précédentes et que votre service Serveur MID est toujours installé sur Madrid ou des versions antérieures, pendant la mise à niveau, le Serveur MID réinstalle automatiquement le service. Pour réinstaller le service, le Serveur MID doit s’exécuter en tant qu’utilisateur administrateur. Si votre mise à niveau de Serveur MID doit réinstaller le service, assurez-vous que l’utilisateur du Serveur MID est administrateur ou vous pouvez réinstaller manuellement le service avant la mise à niveau. Pour plus d’informations sur la réinstallation manuelle du service, reportez-vous à la section KB0821436.

    Quand le MID Server doit-il être mis à niveau ?

    Tout serveur MID avec une version différente de la version de l’instance doit être mis à niveau. Les deux propriétés système suivantes contrôlent la version de tous les MID Server :

    • mid.buildstamp : identifie la version du Serveur MID avec un identificateur basé sur la date de la version. Cette propriété utilise le format mm-jj-aa-hhmm. Le serveur MID recherche les informations de version toutes les heures. Si aucune version de remplacement n’est configurée, le serveur MID examine la propriété mid.buildstamp pour la version à utiliser. Cette propriété se réinitialise à la version par défaut (la version qui correspond à la version de votre instance) lorsque l’instance est redémarrée ou mise à niveau, de sorte que toutes les modifications apportées par l’utilisateur sont perdues à ce moment-là. Le système ajoute le nom de la version et les informations de correctif au format de date et d’heure.
      Avertissement :
      Cette propriété n’est pas visible par défaut et ne doit pas être configurée.
    • mid.version.override : définit une condition de remplacement pour la version actuelle pour tous les serveurs MID de votre environnement. Cette action épingle les serveurs MID à une version unique et désactive la fonctionnalité de mise à niveau automatique. Cette propriété n’est pas visible dans le système de base et doit être ajoutée à la table Propriétés système [sys_properties] lorsqu’elle est définie. Pour plus d’informations, consultez Ajouter une propriété système.

    Lorsque les MID Server vérifient la version toutes les heures, ils examinent d’abord la propriété mid.version.override . Si cette propriété est vide, les MID Server obtiennent leurs informations de version à partir de la propriété mid.buildstamp . Si une version de remplacement est configurée, les MID Server utilisent cette valeur et ignorent les informations de version dans la propriété mid.buildstamp . Cette valeur de remplacement est conservée lorsque l’instance est redémarrée et transmise aux serveurs MID. La valeur de la propriété mid.version.override est effacée lors d’une mise à niveau, ce qui oblige le serveur MID à se réinitialiser à la version dans la propriété mid.buildstamp .

    En plus de mid.version.override, la version du serveur MID peut également être contrôlée avec le paramètre de configuration mid.pinned.version qui épingle le serveur MID à une version spécifique. Pour épingler un serveur MID, définissez le paramètre mid.pinned.version avec le nom de cette version dans le fichier config.xml de chaque serveur MID. Utilisez le format <version>-mm-jj-aaaa. Ce paramètre remplace le paramètre de propriété pour la version épinglée du Serveur MID. Pour obtenir des instructions, consultez Ajouter un paramètre de Serveur MID. La valeur définie dans ce paramètre n’est pas affectée par une mise à niveau.

    Avertissement :
    Il n’est pas recommandé d’utiliser mid.version.override et mid.pinned.version . Les différentes versions sur le serveur MID et l’instance peuvent entraîner des problèmes de panne sur le serveur MID.

    Méthodes de mise à niveau

    Automatique
    La mise à niveau automatique peut être déclenchée par l’instance ou par le serveur MID lui-même. Cette fonctionnalité est disponible par défaut. La mise à niveau automatique se produit :
    • Lorsque l’instance est mise à niveau et que le serveur MID pour cette version est différent de la version actuellement sur le serveur MID. L’instance envoie la commande système autoUpgradeaux MID Server connectés.
    • Toutes les heures, le serveur MID vérifie auprès de l’instance s’il existe une version différente disponible pour la mise à niveau. Vous ne pouvez pas modifier cette période.
    Manuel
    Démarrez manuellement la mise à niveau en cliquant sur un lien connexe sur l’enregistrement du Serveur MID. Utilisez cette méthode lorsque vous ne souhaitez pas attendre la prochaine mise à jour automatique toutes les heures ou si votre mise à niveau a échoué et que vous souhaitez forcer une mise à niveau. Reportez-vous à la section Mise à niveau manuelle du serveur MID pour obtenir des instructions.

    Processus de mise à niveau

    1. Vérification préalable à la mise à niveau :Avant de commencer le processus de mise à niveau du MID Server, celui-ci exécute un ensemble de tests pour s’assurer que l’ordinateur hôte répond aux exigences minimales. Toute erreur rencontrée au cours de ce test automatique empêche la mise à niveau de se produire tant que les problèmes ne sont pas résolus. Le test préalable à la mise à niveau est activé par défaut, mais il peut être désactivé en ajoutant et en définissant une propriété système. Consultez Vérification préalable à la mise à niveau du serveur MID pour plus d'informations.
    2. Téléchargez les packages :Le MID Server télécharge les packages de mise à niveau à partir de install.service-now.com. Ces packages sont au format zip et sont téléchargés dans le dossier agent dans le dossier package/entrant .
    3. Vérification de signature numérique

      Après avoir téléchargé chaque package, MID Server vérifie la signature numérique du package. Une exception est levée en cas d’échec de la vérification. L’erreur est enregistrée dans le journal de l’agent et dans la table des problèmes du Serveur MID.

      Si les packages sont téléchargés et remplacés manuellement, vous pouvez vérifier la signature manuellement. Pour vérifier manuellement la signature d’un package d’installation ou de mise à niveau, utilisez l’outil jarsigner qui est disponible gratuitement avec JDK. Voici la commande jarsigner pour lancer la vérification : Jarsigner -verify -verbose -certs -strict <zip-file>

      La sortie doit être similaire à l’exemple suivant :
      - Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
 
jar verified.
 
The signer certificate will expire on 2021-08-09.
The timestamp will expire on 2029-03-22.
    4. Extraction des fichiers zip :Après avoir téléchargé tous les packages requis, le MID Server extrait les fichiers zip.
      • Avant Rome : les fichiers zip sont extraits dans un dossier sous le dossier temporaire défini par le système d’exploitation. Le nom du dossier est un nombre généré aléatoirement. Le dossier temporaire du système d’exploitation est spécifié par la propriété système java.io.tmpdir. Sur un hôte UNIX, la valeur de cette propriété est généralement /tmp ou /var/tmp.
      • À partir de Rome : le MID Server évite d’utiliser des dossiers temporaires définis par le système d’exploitation lors de la mise à niveau du MID Server. Les fichiers zip sont extraits dans un dossier du dossier de travail/upgrade_temp sous le dossier de l’agent. Le format du nom de dossier est un nombre généré de manière aléatoire. Si vous souhaitez passer au comportement précédent et utiliser un dossier temporaire défini par le système d’exploitation, vous pouvez ajouter mid.upgrade.use_os_temp_folderau fichier config.xml du serveur MID et le définir sur true. Pour changer le comportement de tous les serveurs MID, vous pouvez l’ajouter à la propriété du serveur MID [ecc_agent_property] si le champ Serveur MID était vide.
      Remarque :
      Si vous utilisez KB0747569 pour modifierjava.io.tmpdiret que vous souhaitez le conserver pour les futures mises à niveau à partir de Rome, définissez mid.upgrade.use_os_temp_foldersur vrai après la mise à niveau vers Rome. Si mid.upgrade.use_os_temp_folder n’est pas définie sur vrai, java.io.tmpdir n’est pas appliqué pendant la mise à niveau du MID Server et le dossier sous agent\work\upgrade_temp sera utilisé.
    5. Remplacez les anciens packages par les packages mis à niveau :Après le téléchargement et l’extraction des packages de mise à niveau, le MID Server remplace les anciens fichiers par les nouveaux fichiers et démarre avec la nouvelle version. Pour remplacer les packages, le MID Server démarre un processus nommé Mise à niveau de la distribution de la plateforme ServiceNow et s’arrête. La mise à niveau de la distribution de la plateforme ServiceNow attend que le MID Server se ferme correctement, puis remplace les fichiers requis comme suit :
      • Avant Rome :Le processus supprime tous les fichiers et dossiers des dossiers bin, lib et jre et copie les nouveaux fichiers dans ces dossiers.
      • À partir de Rome : Le processus remplace les fichiers dans les fichiers bin, lib et jre uniquement si la nouvelle version du fichier est différente de l’ancienne version. La mise à niveau de la distribution de la plateforme ServiceNow ne nettoie pas les fichiers de mise à niveau et les fichiers inchangés sont conservés.
      Si la réinstallation du service était requise dans le cadre de la mise à niveau du serveur MID, la mise à niveau de distribution de la plateforme ServiceNow réinstalle le service avant de démarrer le serveur MID. Pour plus d’informations, reportez-vous à KB0821436.
      Remarque :

      Si la mise à niveau du serveur MID échoue à cette étape, le serveur MID reste indisponible. Certains antivirus bloquent le remplacement des fichiers à cette étape. Pour plus d’informations, reportez-vous à KB0870329.

    6. Démarrez le MID Server :Après avoir remplacé tous les fichiers requis par la nouvelle version, la mise à niveau de distribution de la plateforme ServiceNow démarre le serveur MID. Lorsque le MID Server arrive avec la nouvelle version, il nettoie tous les dossiers temporaires utilisés pour extraire les fichiers de mise à niveau.

    Mettre à niveau les messages du journal

    Les messages du journal du Serveur MID sont disponibles dans les fichiers journaux suivants :

    • Les messages du journal de vérification avant mise à niveau sont disponibles dans agent.log fichier sous le dossier agent/logs. Le message Exécution de tests de validation préalables à la mise à niveau. indique que la vérification préalable à la mise à niveau a commencé. Si tous les tests obligatoires sont réussis, le message Tests de validation de pré-mise à niveau réussit. Poursuite du processus de mise à niveau. Indique la fin de la vérification préalable à la mise à niveau.

    • Les messages de journal pour le téléchargement des fichiers manquants sont également disponibles dans agent.log. Chaque téléchargement de package commence par Téléchargement du package à PACKAGENAME.ZIP partir https://install.service-now.com/ message PACKAGEINFO . La progression du téléchargement et la taille du fichier téléchargé sont surveillées dans le journal. Après le téléchargement de chaque package, le package a été téléchargé avec succès à partir de https://install.service-now.com/ PACKAGEINFO indique que le téléchargement a réussi.

    • L’extraction des fichiers zip est la dernière étape disponible dans le agent.log. Le message Mise à niveau du MID Server indique le début de cette étape et le message Extraction du package PACKAGE.ZIP vers EXTRACT_TMP_FOLDER s’affiche pour chaque extraction de package. Lorsque tous les fichiers zip requis sont extraits avec succès, le serveur MID démarre le processus de mise à niveau de la distribution de la plateforme ServiceNow et le message Arrêt du serveur MID. La mise à niveau d’amorçage indique la fin de cette étape avant que Serveur MID ne tombe en panne.
    Distribution de la plateforme ServiceNow Les journaux de mise à niveau incluent des messages de journal pour le démarrage du processus et pour le remplacement de fichiers pendant la mise à niveau du MID Server. Les messages du journal de mise à niveau sont placés entre les messages DÉBUT DE LA CONNEXION PRINCIPALE DE MISE À NIVEAU *********** et FIN DE LA CONNEXION PRINCIPALE DE MISE À NIVEAU ***********. Distribution de la plateforme ServiceNow Les messages de journal de mise à niveau se trouvent dans les fichiers journaux suivants :
    • Dans le fichier glide-dist-upgrade.log sous le dossier d’extraction temporaire. Ce fichier est disponible dans le dossier upgrade-wrapper/logs sous le dossier temp extract. Ce fichier journal inclut les messages du journal de processus et les messages du journal de mise à niveau.
    • Dans le fichier dist-upgrade.log dans le dossier agent\logs . Ce fichier inclut uniquement la partie mise à niveau des messages du journal. S’il y a eu un problème avec le démarrage du processus, vous devez regarder glide-dist-upgrade.log.
    • Dans wrapper.logsous le dossier agent\logs . Après le remplacement des fichiers, la mise à niveau de la distribution de la plateforme ServiceNow ajoute glide-dist-upgrade.log au fichier wrapper.log.

    Mettre à jour la configuration de la couche avec upgrade-wrapper-override.conf

    La configuration du wrapper pour glide-dist-upgrade peut être mise à jour à l’aide d’un fichier upgrade-wrapper-override.conf . Créez un fichier nommé upgrade-wrapper-override.conf dans le dossier agent/conf . Toutes les configurations dans le fichier upgrade-wrapper-override.conf sont utilisées pendant le processus de mise à niveau.

    En modifiant la configuration avec upgrade-wrapper-override.conf, les journaux de débogage peuvent être activés au niveau du wrapper dist-upgrade et les changements peuvent être testés.

    Par exemple, le délai d’expiration par défaut peut ne pas être assez long pour certaines commandes de niveau JVM. Le délai d’expiration peut être augmenté avec upgrade-wrapper-override.conf pour la configuration dist-upgrade wrapper.

    États du Serveur MID

    Mise à niveau
    L’état du serveur MID passe à Mise à niveau pendant l’exécution de la mise à niveau. L’état de mise à niveau est similaire à l’état de pause . Cela permet d’éviter les malentendus entre la nouvelle version de l’instance et la version précédente du serveur MID pendant la mise à niveau. Lorsque vous êtes dans l’état de mise à niveau, vous ne pouvez pas reprendre ou redémarrer le MID Server. Toutefois, vous pouvez effectuer les mêmes actions que lorsque le MID Server est en état de pause.
    Remarque :
    Si vous utilisez une instance Istanbul, mais que vous mettez à niveau un serveur MID antérieur à Istanbul vers Istanbul, ces états de mise à niveau ne sont pas disponibles. Ils ne sont disponibles que pour les MID Servers qui se trouvent déjà à Istanbul.
    Échec de la mise à niveau
    Si la mise à niveau a échoué à l’étape de vérification préalable à la mise à niveau ou à l’étape de téléchargement/extraction de packages, les échecs de mise à niveau sont traités différemment en fonction de la version que vous mettez à niveau.
    • Mise à niveau vers une autre version majeure (par exemple, Istanbul vers la version complète suivante) : l’état passe à Échec de la mise à niveau.
    • Mettre à niveau à partir d’une version mineure au sein d’une mise en production (comme le correctif Jakarta 1 vers le correctif 2) : le serveur MID continue d’utiliser la version qu’il exécute actuellement. Il n’effectue pas la mise à niveau et l’état finit par passer à Actif, en supposant que le MID Server fonctionnait déjà correctement.
    • Si la mise à niveau a échoué lors de la dernière étape, le remplacement de l’ancienne version des packages par la nouvelle version des packages, le serveur MID reste indisponible.

    Historique des mises à niveau du Serveur MID

    Utilisez le module Historique des mises à niveau du Serveur MID pour résoudre les problèmes liés aux mises à niveau du Serveur MID. Le module contient un enregistrement de chaque mise à niveau d’instance. Ces enregistrements fournissent des détails d’état étape par étape pour le processus de mise à niveau de chaque MID Server. Si une erreur se produit, elle est notée à l’étape et un message est généré dynamiquement avec plus de détails. La tâche de nettoyage de table supprime automatiquement les problèmes qui n’ont pas été détectés pendant 30 jours, quel que soit leur état. Pour plus d’informations, consultez Historique des mises à niveau du Serveur MID.

    Migration des certificats JRE TrustStore pendant les mises à jour JRE

    Pour les mises à jour de JRE après la mise à niveau vers Quebec, le MID Server migre les certificats auto-signés existants dans le JRE TrustStore vers le TrustStore de la nouvelle version JRE. Lorsque ces certificats sont migrés, leurs alias sont précédés de la chaîne « snc_ ».

    Pour qu’un certificat puisse être migré, il doit être :

    • un certificat X509
    • Norme de certification v3
    • avoir l’extension de contrainte de base définie sur faux (c’est-à-dire qu’elle n’est pas émise par l’autorité de certification)

    Le MID Server identifie quand une mise à niveau JRE est sur le point d’avoir lieu et commence le processus de migration. Avant la migration, le MID Server crée une sauvegarde du TrustStore d’origine comme solution de secours en cas de défaillance. En cas d’échec, le TrustStore de sauvegarde peut être restauré manuellement.