Mises à niveau de Serveur MID

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 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 de 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 des instructions pour réactiver ce service, consultez la rubrique KB0597552.

    Exigences relatives à la mise à niveau de 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 à install.service-now.com pour effectuer une mise à niveau automatique. 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 du programme d’installation de Serveur MID dans vos hôtes de Serveur MID. Pour obtenir des instructions, consultez KB0760123 dans la base de connaissances auto-hébergée.
    Accès du serveur MID à OCSP bloqué
    Les pare-feu et les configurations proxy peuvent bloquer les appels vers les serveurs OCSP Entrust et DigiCert, ce qui empêche le MID Server de fonctionner. Vous devrez peut-être modifier les autorisations de votre pare-feu pour que le trafic OCSP passe. Pour plus d’informations et de résolutions, consultez l’article de la base de connaissances HI [KB1216223].
    Compatibilité du système d’exploitation MID Server
    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 de 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 des instructions pour réactiver ce service, consultez la rubrique KB0597552.

    La mise à niveau du Serveur MID est bloquée par certains antivirus en cours d’exécution sur des 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 un système de 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, 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 de Serveur MID est un administrateur, ou vous pouvez réinstaller manuellement le service avant la mise à niveau. Pour en savoir plus sur la réinstallation manuelle du service, reportez-vous à la rubrique KB0821436.

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

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

    • 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-aaaa-hhmm. Le serveur MID vérifie 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 connaître 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 tous les changements de l’utilisateur sont perdus à ce moment-là. Le système ajoute le nom de la mise en production et les informations sur le 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 de tous les serveurs MID de votre environnement. Cette action épingle les MID Servers à 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 en savoir plus, consultez Ajouter une propriété système.

    Lorsque les MID Servers 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 Servers obtiennent leurs informations de version à partir de la propriété mid.buildstamp . Si une version de remplacement est configurée, les serveurs MID 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 force le serveur MID à se réinitialiser à la version de 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é de la version de Serveur MID épinglée. 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 :
    L’utilisation de mid.version.override et mid.pinned.version n’est pas recommandée. 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 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 de cette version est différent de la version actuellement sur le serveur MID. L’instance envoie la commande système autoUpgradeaux MID Servers 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 voulez 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. Consultez 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 Serveur MID, celui-ci exécute une série de tests pour s’assurer que l’ordinateur hôte répond aux exigences minimales. Les erreurs rencontrées pendant ce test automatique empêchent la mise à niveau de se produire jusqu’à ce que les problèmes soient résolus. Le test préalable à la mise à niveau est activé par défaut, mais vous pouvez le désactiver en ajoutant et en définissant une propriété système. Consultez Vérification préalable à la mise à niveau de Serveur MID pour plus d'informations.
    2. Télécharger les packages :Le serveur MID 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 de l’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. Il lève une exception si la vérification échoue. L’erreur sera enregistrée dans le journal de l’agent et dans la table des problèmes de Serveur MID.

      Si les paquets 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. La commande jarsigner pour lancer la vérification est la suivante : Jarsigner -verify -verbose -certs -strict <fichier-zip>

      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 serveur MID 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é de façon aléatoire. 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 serveur MID évite d’utiliser les dossiers temporaires définis par le système d’exploitation lors de la mise à niveau du serveur MID. Les fichiers zip sont extraits dans un dossier dans le dossier work/upgrade_temp sous le dossier agent. Le format du nom de dossier est un nombre généré de façon aléatoire. Si vous souhaitez revenir 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é de Serveur MID [ecc_agent_property] avec le champ Serveur MID vide.
      Remarque :
      Si vous utilisez KB0747569 pour modifierjava.io.tmpdiret que vous souhaitez le conserver pour les futures mises à jour à 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éfini sur vrai, java.io.tmpdir n’est pas appliqué lors de la mise à niveau du serveur MID et le dossier sous agent\work\upgrade_temp est utilisé.
    5. Remplacez les anciens packages par les packages mis à niveau :Après avoir téléchargé et extrait les packages de mise à niveau, le serveur MID remplace les anciens fichiers par les nouveaux fichiers et commence avec la nouvelle version. Pour remplacer les packages, le Serveur MID démarre un processus nommé Mise à niveau de Distribution de la plateforme ServiceNow et s’arrête. La mise à niveau de la distribution de la plateforme ServiceNow attend que le serveur MID s’arrête correctement, puis remplace les fichiers requis comme suit :
      • Avant Rome :Le processus supprime tous les fichiers et dossiers dans les dossiers bin, lib et jre et copie les nouveaux fichiers dans ces dossiers.
      • À partir de Rome : Le processus remplace les fichiers dans le bin, lib et jre uniquement si la nouvelle version du fichier est différente de l’ancienne version. La mise à niveau de ServiceNow Platform Distribution ne nettoie pas les fichiers de mise à niveau et les fichiers inchangés sont conservés.
      Si le service de réinstallation était requis dans le cadre de la mise à niveau de Serveur MID, ServiceNow Platform Distribution Upgrade réinstalle le service avant de démarrer Serveur MID. Pour plus d’informations, reportez-vous à KB0821436.
      Remarque :

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

    6. Démarrez le Serveur MID :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 fournit 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 préalable à la mise à niveau sont disponibles dans agent.log fichier dans le dossier agent/logs. Le message Exécution des 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 réussissent, le message Tests de validation préalable à la mise à niveau réussis. 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 de 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 avoir téléchargé chaque package, le package a été téléchargé avec succès à partir de https://install.service-now.com/ PACKAGEINFO indique le téléchargement réussi.

    • L’extraction des fichiers zip est la dernière étape disponible dans le agent.log. Le message Mise à niveau du serveur MID indique le début de cette étape et le message Extraction du package PACKAGE.ZIP à EXTRACT_TMP_FOLDER s’affiche pour chaque extraction de package. Lorsque tous les fichiers zip requis sont extraits avec succès, Serveur MID démarre le processus de mise à niveau de Distribution de la plateforme ServiceNow et affiche le message Arrêt du Serveur MID. La mise à niveau d’amorçage affiche la fin de cette étape avant que Serveur MID ne tombe en panne.
    Les journaux de mise à niveau de ServiceNow Platform Distribution incluent des messages de journal pour le démarrage du processus et pour le remplacement de fichiers pendant la mise à niveau de Serveur MID. 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***********. Les messages du journal de mise à niveau de la distribution de la plateforme ServiceNow 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 d’extraction temporaire. Ce fichier journal inclut les messages du journal des processus et des 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 examiner glide-dist-upgrade.log.
    • Dans wrapper.logsous le dossier agent\logs . Après avoir remplacé les fichiers, ServiceNow Platform Distribution Upgrade ajoute glide-dist-upgrade.log au fichier wrapper.log.

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

    La configuration de la couche 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 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 de la couche 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 de la couche dist-upgrade .

    États de Serveur MID

    Mise à niveau
    L’état du serveur MID est passé à Mise à niveau pendant l’exécution de la mise à niveau. L’état Mise à niveau est similaire à l’état Pause . Cela évite les problèmes potentiels de communication 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 Mise à niveau, vous ne pouvez pas reprendre ou redémarrer le serveur MID. Toutefois, vous pouvez effectuer les mêmes actions que lorsque le Serveur MID est en pause.
    Remarque :
    Si vous utilisez une instance d’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 serveurs MID qui se trouvent déjà sur 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 mises à niveau ayant échoué sont traitées différemment selon la version que vous mettez à niveau.
    • Effectuez une mise à niveau vers une autre version majeure (par exemple, d’Istanbul vers la prochaine version complète) : l’état passe à Échec de la mise à niveau.
    • Mise à niveau d’une version mineure au sein d’une version (par exemple, du correctif Jakarta 1 au 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 à Haut, en supposant que le serveur MID fonctionnait déjà correctement.
    • Si la mise à niveau a échoué à la dernière étape, en remplaçant l’ancienne version des packages par la nouvelle version des packages, le serveur MID reste en panne.

    Historique des mises à niveau du Serveur MID

    Utilisez le module Historique des mises à niveau de Serveur MID pour résoudre les problèmes liés aux mises à niveau de 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 chaque processus de mise à niveau de Serveur MID. Si une erreur se produit, elle est notée dans 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 depuis 30 jours, quel que soit leur état. Pour plus d’informations, consultez Historique des mises à niveau du Serveur MID.

    Migration du certificat du magasin de clés de confiance JRE pendant les mises à jour JRE

    Pour les mises à jour JRE après la mise à niveau vers Quebec, le Serveur MID migre les certificats auto-signés existants dans le TrustStore JRE 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 certificat 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 serveur MID identifie quand une mise à niveau JRE est sur le point d’avoir lieu et commence le processus de migration. Avant la migration, le Serveur MID crée une sauvegarde du TrustStore d’origine en cas de panne. En cas de défaillance, le TrustStore de sauvegarde peut être restauré manuellement.