8 Mise à niveau vers STA 2.1.0

Ce chapitre fournit les instructions de mise à niveau de toute version précédente de STA vers STA 2.1.0. Il contient les sections suivantes :

S'il s'agit d'une première installation de STA, vous devez effectuer une nouvelle installation de base, reportez-vous à au chapitre Chapitre 3, Installation de STA pour connaitre les instructions.

L'annexe Annexe C comporte des fiches à utiliser pour organiser vos activités de mise à niveau et enregistrer vos paramètres.

Présentation du processus de mise à niveau

Pendant une mise à niveau, vos données STA existantes sont transformées de la version STA actuelle en données de la nouvelle version. Votre base de données STA n'est pas valide avec la nouvelle version de STA jusqu'à ce que ces transformations soient effectuées. Après la mise à niveau, STA traitera de nouvelles données en fonction du nouveau schéma et des nouvelles règles d'analyse ; les données d'historique ne sont pas à nouveau traitées.

Avant de commencer la mise à niveau, lisez toutes les instructions de ce chapitre, et assurez-vous de disposer de suffisamment de temps pour effectuer le processus dans son entier. Certaines tâches de préparation de mise à niveau peuvent demander une coordination avec d'autres groupes de votre site, tel que l'administration réseau. Toutes les tâches de préparation doivent être effectuées à l'avance, afin de terminer la mise à niveau aussi rapidement que possible.

Une fois le processus de mise à niveau commencé, STA ne peut pas être en cours d'exécution, et ne reçoit donc pas les informations d'échange des bibliothèques contrôlées. En outre, la nouvelle version de STA ne commence pas à recevoir d'informations des bibliothèques avant que vous n'ayez terminé toutes les étapes de la mise à niveau et testé la connexion SNMP vers chaque bibliothèque contrôlée.

Remarque:

Certaines étapes de la mise à niveau comportent des estimations de temps, qui ne sont fournies qu'à des fins de planification. Selon les capacités de votre serveur — nombre de CPU, vitesse CPU, vitesse des disques, mémoire et espace de swap disponible — ces durées peuvent varier.

Chemins de mise à niveau STA 2.1.0 valides

Vous pouvez mettre à niveau vers STA 2.1.0 depuis toutes les versions STA suivantes :

  • STA 2.0.x:

    • STA 2.0.0.83

    • STA 2.0.1.4

  • STA 1.0.x:

    • STA 1.0.0.99

    • STA 1.0.1.133

    • STA 1.0.2.24

    Remarque:

    Si vous effectuez une mise à niveau de STA 1.0.x, vous devez également installer une nouvelle version de Linux avant d'installer STA 2.1.0. Pour plus d'informations, reportez-vous au guide Guide des conditions requises pour l'installation de STA.

Méthodes de mise à niveau

Selon vos buts et vos ressources disponibles, vous pouvez effectuer la mise à niveau de STA avec un ou deux serveurs. Les tâches de mise à niveau sont principalement communes aux deux méthodes, mais leur ordre d'exécution diffère. Ces deux méthodes sont décrites dans les sections suivantes :

Méthode de mise à niveau à serveur unique

Avec cette méthode, vous devez désinstaller STA avant d'installer la nouvelle version, et mettre à niveau la base de données sur ce serveur. Pendant ce processus, STA ne contrôle pas les bibliothèques.

Cette méthode présente l'avantage de ne pas nécessiter de serveur supplémentaire dédié à la mise à niveau. Si vous effectuez une mise à niveau depuis STA 2.0.x, vous n'avez pas besoin d'installer une nouvelle version de Linux, cette méthode peut donc suffire à vos besoins.

La copie d'écran Figure 8-1 illustre la méthode à serveur unique. Vous exécuterez les tâches de 1 à 9 dans l'ordre indiqué. En résumé :

  • Effectuez le vidage de la base de données actuelle, et transférez-le vers un serveur de sauvegarde à des fins de conservation (Tâche 1 et Tâche 2).

  • Selon votre version actuelle de STA, installez Linux 6.x (Tâche 3a) ou désinstallez STA 2.0.x (Tâche 3b).

  • Installez STA 2.1.0, et par mesure de précaution, effectuez le vidage de la nouvelle base de données (Tâche 4 et Tâche 5).

  • Transférez le vidage de l'ancienne base de données depuis le serveur de sauvegarde, puis chargez-le et mettez-le à niveau vers la nouvelle version de STA (Tâche 6 à Tâche 8).

  • Rétablissez les connexions vers les bibliothèques contrôlées et effectuez les tâches de configuration manuelle nécessaires (Tâche 9). L'ancienne version de STA devant être désinstallée avant d'installer STA 2.1.0, vous devez ressaisir manuellement certaines données utilisateur de configuration.

Figure 8-1 Présentation de la tâche de mise à niveau avec serveur unique

La description de Figure 8-1 est la suivante
Description de Figure 8-1 Présentation de la tâche de mise à niveau avec serveur unique

Méthode de mise à niveau à deux serveurs

La méthode de mise à niveau à deux serveurs requiert un second serveur STA dédié, mais elle présente l'avantage de réduire le temps d'arrêt de l'application STA. Cette méthode est particulièrement utile pour la mise à niveau de STA 1.0.x, car l'ancienne version de STA peut continuer à contrôler les bibliothèques sur l'ancien serveur tandis que Linux comme la nouvelle version de STA sont installés sur le nouveau serveur.

Cependant, même avec cette méthode, STA ne contrôle pas les bibliothèques pendant la mise à niveau de la base de données actuelle vers la nouvelle version de STA. La durée de temps d'arrêt dépend de la taille de votre base de données actuelle.

La copie d'écran Figure 8-2 présente la méthode de mise à niveau à deux serveurs. Vous devez effectuer les tâches dans l'ordre indiqué — elles ne sont pas effectuées par ordre séquentiel, et la tâche 6 est omise. Notez que vous n'effectuez pas de vidage de la base de données STA actuelle avant d'avoir installé la nouvelle version de STA sur le nouveau serveur. En résumé :

  • Selon que le second serveur exécute actuellement une version de STA, installez Linux 6.x (Tâche 3a) ou désinstallez STA 2.0.x (Tâche 3b).

  • Installez STA 2.1.0 sur le nouveau serveur, et par mesure de précaution, effectuez le vidage de la nouvelle base de données (Tâche 4 et Tâche 5).

  • Effectuez le vidage de la base de données actuelle sur l'ancien serveur, et transférez-la vers le nouveau serveur (Tâche 1 et Tâche 2).

  • Chargez et mettez à niveau la base de données actuelle vers la nouvelle version de STA (Tâche 7 et Tâche 8).

  • Rétablissez les connexions vers les bibliothèques contrôlées et effectuez les tâches de configuration manuelle nécessaires (Tâche 9).

Figure 8-2 Présentation de la tâche de mise à niveau avec deux serveurs

La description de Figure 8-2 est la suivante
Description de Figure 8-2 Présentation de la tâche de mise à niveau avec deux serveurs

Modifications d'environnement pour STA 2.1.0

Un résumé des modifications d'environnement à prendre en compte lorsque vous envisagez la mise à niveau vers STA 2.1.0 est présenté ci-dessous.

Version de Linux

STA 2.1.0 requiert Linux 6.3 ou ultérieure (Pour plus d'informations, reportez-vous au guide Guide des conditions requises pour l'installation de STA). Selon votre version actuelle de STA, pour pourrez devoir installer une nouvelle version de Linux dans le cadre du processus de mise à niveau de STA.

  • Si vous effectuez la mise à niveau depuis STA 1.0.x, vous devez installer Linux 6.3 ou supérieure avant d'installer STA 2.1.0. Linux ne prend pas en charge une mise à niveau en place de Linux 5.x vers Linux 6.x ; vous devrez à la place effectuer une nouvelle installation de Linux 6.x sur le serveur STA.

  • Si vous effectuez la mise à niveau de STA 2.0.x, vous exécutez déjà Linux 6.3 ou supérieure ; vous devez cependant désinstaller la version actuelle de STA avant d'installer STA 2.1.0. Il est également possible que vous deviez installer ou mettre à niveau les packages Linux RPM requis—dans le cadre de la préparation à la mise à niveau, vous vous assurerez que tous les niveaux requis de package RPM sont installés, et, en vérification finale, le programme d'installation de STA vous préviendra en cas de packages manquants.

Numéros de port WebLogic par défaut

Les numéros de port de la console d'administration WebLogic par défaut ont été modifiés pour STA 2.1.0. Si vous utilisez actuellement les anciens numéros de port par défaut, vous pourrez souhaiter les remplacer par les nouveaux. Les nouveaux et anciens numéros de port par défaut sont les suivants :

  • Nouveaux numéros par défaut pour STA 2.1.0—7019 (HTTP) et 7020 (HTTPS)

  • Anciens numéros par défaut pour (STA 1.0.x et STA 2.x)—7001 (HTTP) et 7002 (HTTPS)

Remarque:

Les ports de la console d'administration WebLogic sont externes. Votre administrateur réseau peut devoir configurer des pare-feu et des routeurs pour ouvrir la communication entre le serveur STA et les clients accédant à l'interface d'administration WebLogic.

Ports requis pour STA 2.0.x et ultérieure

Remarque:

Cette modification a été introduite dans STA 2.0.x, cette opération n'est donc pertinente que si vous effectuez une mise à niveau de STA 1.0.x.

Dans STA 2.0.x, des ports STA ont été ajoutés pour les serveurs gérés StaUi et StaEngine. Les numéros de port des serveurs gérés STA par défaut pour STA2.0.x et STA 2.1.0 sont les suivants :

  • StaUi—7021 (HTTP) et 7022 (HTTPS)

  • StaEngine—7023 (HTTP) et 7024 (HTTPS)

  • StaAdapter—7025 (HTTP) et 7026 (HTTPS)

Remarque:

Les ports StaUi sont externes. Votre administrateur réseau peut devoir configurer des pare-feu et des routeurs pour ouvrir la communication entre le serveur STA et les clients accédant à l'interface utilisateur STA.

Conditions requises de nom d'utilisateur et de mot de passe

Les conditions requises de nom d'utilisateur et de mot de passe pour STA et MySQL ont été modifiées pour STA 2.1.0. Vous pourrez devoir coordonner ces conditions avec les conditions internes de votre site.

Les conditions du nom d'utilisateur requises sont les suivantes :

  • Il doit comporter entre 1 et 16 caractères.

  • Tous les noms d'utilisateur doivent être uniques.

Les conditions requises en termes de mot de passe sont les suivantes :

  • Il doit comporter entre 8 et 31 caractères.

  • Il doit comporter au moins un chiffre et une majuscule

  • Il ne doit pas comporter d'espace

  • Il ne doit pas comporter les caractères spéciaux suivants :

    & ' ( ) < > ? { } *  \ ' "

Tâches de préparation de la mise à niveau

Les tâches suivantes doivent être exécutées avant de commencer la mise à niveau de STA. La plupart de ces tâches sont facultatives, et le tableau Tableau 8-1 indique quand utiliser chacune d'entre elles.

Tableau 8-1 Directives relatives au moment d'exécuter les tâches de préparation de la mise à niveau

Tâche Quand l'exécuter

Vérifiez que votre site est prêt pour la mise à niveau

Toutes les mises à niveau

Enregistrement des journaux existants (facultatif)

Vous souhaitez conserver les journaux de service de la version actuelle de STA.

Enregistrement de l'utilisateur STA et des paramètres de configuration actuels (facultatif)

Vous souhaitez conserver les noms d'utilisateur et les paramètres de configuration actuels de STA.

Renommage des modèles personnalisés avec préfixe STA– (facultatif)

Vous disposez de modèles personnalisés avec des noms ayant comme préfixe "STA–".

Enregistrement des paramètres actuels de modèle personnalisé (facultatif)

Vous souhaitez conserver les paramètres de propriété et de visibilité des modèles personnalisés existants.

Enregistrement des paramètres de stratégie de rapport exécutif (facultatif)

Vous souhaitez conserver les paramètres de propriété pour les stratégies de rapports exécutifs existantes.

Vérifiez que votre site est prêt pour la mise à niveau

Suivez cette procédure pour vérifier les prérequis de la mise à jour et que votre site est prêt.

Vérification des prérequis de la mise à niveau

Suivez cette procédure pour vous assurer que votre environnement répond aux prérequis de STA 2.1.0.

  1. Affichez votre version actuelle de STA. Certaines tâches de mise à niveau varient selon que vous effectuez la mise à niveau de STA 1.0.x ou STA 2.0.x.

    1. Connectez-vous à STA avec un nom d'administrateur STA.

    2. Cliquez sur About dans la barre d'état.

    3. Vérifiez que la version de STA est actuelle. Pour plus d'informations, reportez-vous à la section Chemins de mise à niveau STA 2.1.0 valides.

  2. Déterminez la méthode à utiliser pour effectuer la mise à niveau, à serveur unique ou à deux serveurs. Pour plus d'informations, reportez-vous à la section Présentation du processus de mise à niveau.

  3. Vérifiez que votre site et le serveur cible répondent aux conditions requises de STA 2.1.0. Pour plus d'informations, reportez-vous au guide Guide des conditions requises pour l'installation de STA.

  4. Déterminez si le système de fichiers /tmp sur le serveur cible STA dispose d'assez d'espace pour la mise à niveau. La taille de /tmp doit être au moins équivalente à celle de votre base de données STA non compressée ; un minimum de 4 Go est requis, et, pour les grandes bases de données, Oracle recommande d'augmenter la taille de /tmp à 32 Go, au minimum.

    Si vous estimez que vous devez augmenter la taille de /tmp, vous pouvez le faire juste avant d'exécuter le script de mise à niveau ; reportez-vous aux instructions de la sectionTâche 8 : Mise à niveau de l'ancienne base de données.

  5. Passez en revue les modifications d'environnement concernant votre chemin de mise à niveau, effectuez les ajustements nécessaires à votre plan ou à votre environnement. Pour plus d'informations, reportez-vous à la section Modifications d'environnement pour STA 2.1.0.

  6. Si vous effectuez une mise à niveau de STA 2.0.x, assurez-vous que tous les packages RPM requis sont installés sur le serveur STA. Pour plus d'informations, reportez-vous à la section Installation des packages Linux requis. En vérification finale, le programme d'installation de STA vous préviendra également en cas de packages manquants.

Vérification de l'activité actuelle de STA

Suivez cette procédure pour vérifier que votre environnement STA actuel fonctionne normalement.

  1. Les étapes suivantes servent à vérifier que la version actuelle de STA a récemment eu une communication avec chaque bibliothèque contrôlée.

    1. Connectez-vous à STA en tant qu'administrateur STA.

    2. Sous l'onglet Setup & Administration , sélectionnez SNMP Connections.

    3. Vérifiez les valeurs suivantes dans le tableau des librairies surveillées :

      • État de la communication de déroutement SNMP récent — GOOD

      • Statut de la dernière connexion — SUCCESS

  2. Les étapes suivantes servent à vérifier que STA traite les échanges entre toutes les bibliothèques.

    1. Sous l'onglet Tape System Activity, sélectionnez Exchanges – Overview.

    2. Sélectionnez l'icône Filter et appliquez le filtre Exchange End (No. Days) Less Than 1.

    3. Dans la barre d'outils du tableau, sélectionnez View, puis Sort, et Advanced. Triez par nom de bibliothèque de lecteurs ou par numéro de série de lecteur.

    4. Vérifiez que toutes les bibliothèques ont une activité d'échange.

Enregistrement des journaux existants (facultatif)

Les journaux de service et d'application existants ne sont pas conservés après la mise à niveau, car vous devez désinstaller la version actuelle de STA ou installer une nouvelle version de Linux avant d'installer STA 2.1.0. Suivez cette procédure pour enregistrer tous les journaux que vous souhaitez conserver.

  1. Déterminez l'emplacement des journaux de base de données et d'installation que vous souhaitez conserver et déplacez-les vers un emplacement sûr. Les journaux pouvant vous intéresser sont situés à l'emplacement des journaux STA que vous avez défini pour votre installation. Pour plus d'informations, reportez-vous à la section Examen de la disposition du système de fichiers STA.

  2. Les étapes suivantes servent à effectuer un instantané de journal de service sur l'installation de STA actuelle. Cet étape est facultative, mais recommandée, car l'assistance Oracle peut utiliser ces journaux pour résoudre des problèmes ayant pu survenir avant la mise à niveau.

    1. Connectez-vous à STA en tant qu'administrateur STA.

    2. Sous l'onglet Setup & Administration, sélectionnez Logs.

    3. A l'écran Service – Logs, cliquez sur l'icône Create New Log Bundle.

    4. Dans la boîte de dialogue Create New Log Bundle, affectez un nom de bundle et cliquez sur Save. Ce processus peut durer plusieurs minutes.

  3. Suivez les étapes suivantes pour télécharger le bundle de journaux de service que vous venez de créer, ainsi que tout autre bundle que vous souhaitez conserver. Vous devez télécharger les journaux un par un.

    1. Sur l'écran Service – Logs, sélectionnez le bundle que vous souhaitez télécharger.

    2. Cliquez sur l'icône Download Selected Log Bundle.

    3. Dans la boîte de dialogue, indiquez l'emplacement cible et enregistrez le bundle de journaux.

Enregistrement de l'utilisateur STA et des paramètres de configuration actuels (facultatif)

Cette section ne s'applique que si vous souhaitez conserver les noms d'utilisateur STA et les paramètres de configuration actuels dans STA 2.1.0. Suivez ces procédures pour afficher et enregistrer les valeurs actuelles afin de les ressaisir pour STA 2.1.0. Vous ressaisirez la plupart de ces valeurs après la mise à niveau ; pour plus d'informations, reportez-vous à la section Tâche 9 : Configuration de la nouvelle version de STA.

Enregistrement des noms d'utilisateur MySQL

Suivez cette procédure pour afficher et enregistrer des noms d'utilisateur MySQL existants utilisés pour accéder à la base de données STA. Le programme d'installation de STA vous invitera à saisir ces valeurs. Il est impossible de récupérer les mots de passe.

  1. Ouvrez une session de terminal sur le serveur STA actuel et connectez-vous en tant qu'utilisateur root du système.

  2. Affichez tous les noms d'utilisateur de la base de données STA avec la requête suivante. A l'invite, saisissez le mot de passe de l'utilisateur root de base de données. Par exemple :

    $ mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql
Enter password: password
+--------+
| user   |
+--------+
| root   |
| staapp |
| stadba |
| starpt |
+--------+

  3. Enregistrez les noms d'utilisateur.

Enregistrement des paramètres client SNMP STA

Suivez cette procédure pour afficher et enregistrer les paramètres client SNMP de STA. Vous ressaisirez la plupart de ces valeurs après la mise à niveau.

Remarque:

Dans la nouvelle version de STA, les valeurs SNMP doivent correspondre à l'indication sur les bibliothèques contrôlées.

  1. Connectez-vous à STA avec un nom d'administrateur STA.

  2. Sous l'onglet Setup & Administration, sélectionnez SNMP Connections.

    Le tableau Attributs client affiche les paramètres de configuration du client SNMP STA.

    La description de snmp_clientupgrade.png est la suivante
    Description de l'illustration snmp_clientupgrade.png

  3. Enregistrez les valeurs depuis les colonnes suivantes :

    • SNMP Username

    • User Community

    • Trap Community

Enregistrement des noms d'utilisateur WebLogic — Mises à niveau de STA 1.0.x uniquement

Pour les mises à jour de STA 1.0.x, suivez cette procédure pour afficher et enregistrer les noms d'utilisateur WebLogic utilisés pour vous connecter à STA. Vous ressaisirez la plupart de ces valeurs après la mise à niveau. Il est impossible de récupérer les mots de passe.

Remarque:

Depuis STA 2.0.x, les noms d'utilisateur sont créés et conservés via l'interface utilisateur de STA ; pour obtenir des instructions, reportez-vous à la section Enregistrement des noms d'utilisateur STA — Mises à niveau de STA 2.0.x uniquement.

  1. Lancez un navigateur Web pris en charge sur votre ordinateur et saisissez l'URL de la console d'administration WebLogic.

    http(s)://STA_host_name:port_number/console/

    Où :

    • host_name est le nom d'hôte du serveur STA.

    • port_number est le numéro de port STA de la console d'administration WebLogic dans la version STA actuelle.

    • STA doit être saisi en majuscules.

    Par exemple :

    https://staserver.example.com:7002/console/

  2. Connectez-vous à l'aide du nom d'utilisateur et du mot de passe de la console d'administration WebLogic.

  3. Dans l'arborescence de navigation de la structure du domaine, cliquez sur Security Realms.

    La description de wl_secrealm.png est la suivante
    Description de l'illustration wl_secrealm.png

    L'écran récapitulatif des Security Realms apparait.

  4. Dans la colonne Name, sélectionnez le lien actif myrealm (ne sélectionnez pas la case).

    La description de wl_myrealm.png est la suivante
    Description de l'illustration wl_myrealm.png

    L'écran Settings for myrealm apparait.

  5. Sélectionnez l'onglet Users and Groups .

    La description de wl_checkusers.png est la suivante
    Description de l'illustration wl_checkusers.png

    Le tableau Users répertorie les noms d'utilisateur disponibles.

    La description de wl_userstable.png est la suivante
    Description de l'illustration wl_userstable.png

  6. Enregistrez les noms d'utilisateur à conserver.

Enregistrement des noms d'utilisateur STA — Mises à niveau de STA 2.0.x uniquement

Pour les mises à jour de STA 2.0.x, suivez cette procédure pour afficher et enregistrer les noms d'utilisateur utilisés pour vous connecter à STA. Vous ressaisirez ces informations après la mise à niveau. Il est impossible de récupérer les mots de passe.

Remarque:

Les noms d'utilisateur de STA 1.0.x sont créés et conservés via la console d'administration WebLogic ; pour connaitre les instructions, reportez-vous à la section Enregistrement des noms d'utilisateur WebLogic — Mises à niveau de STA 1.0.x uniquement.

  1. Connectez-vous à STA avec un nom d'administrateur STA.

  2. Sous l'onglet Setup & Administration, sélectionnez Users.

    L'écran Configuration – Users présente tous les noms d'utilisateur STA et leur rôles.

    La description de upgrade_users.png est la suivante
    Description de l'illustration upgrade_users.png

  3. Enregistrez les noms d'utilisateur et les rôles à conserver.

Enregistrement des paramètres du serveur de messagerie STA

Suivez cette procédure pour afficher et enregistrer le protocole de messagerie STA et le nom d'utilisateur du compte, dans le cas où le serveur de messagerie requiert une authentification. Vous ressaisirez la plupart de ces valeurs après la mise à niveau. Le mot de passe ne s'affiche pas.

  1. Connectez-vous à STA avec un nom d'administrateur STA.

  2. Sous l'onglet Setup & Administration, sélectionnez Email.

  3. Dans le tableau des paramètres serveur SMTP, sélectionnez l'enregistrement Alertes StorageTek Tape Analytics, puis cliquez sur l'icôneEdit Selected SMTP Server.

    La boîte de dialogue Define SMTP Server apparait.

    La description de email_smtpserverd.png est la suivante
    Description de l'illustration email_smtpserverd.png

  4. Enregistrez les valeurs des champs suivants :

    • Use Secure Connection Protocol

    • Username

Renommage des modèles personnalisés avec préfixe STA– (facultatif)

Cette procédure ne s'applique que si vous disposez de modèles personnalisés avec le préfixe "STA–". Pendant l'installation de STA 2.1.0, tous les modèles au préfixe "STA–" sont supprimés et remplacés par de nouveaux modèles STA prédéfinis.

Suivez cette procédure pour affecter de nouveaux noms aux modèles afin de les conserver pendant la mise à niveau.

Remarque:

Les modèles prédéfinis STA portent le préfixe "STA–" ; Oracle recommande donc de ne pas utiliser ce préfixe pour nommer des modèles personnalisés.

  1. Connectez-vous à STA avec un nom d'administrateur.

  2. Sous l'ongletSetup & Administration, sélectionnez Templates Management.

  3. Triez le tableau par la date de création/mise à jour, pour cibler les modèles modifiés depuis la date d'installation de STA.

  4. Sélectionnez le lien de texte d'un modèle personnalisé portant le préfixe "STA–".

    Vous êtes renvoyé vers l'écran où le modèle sélectionné est appliqué.

  5. Cliquez sur Save Template dans la barre d'outils Templates.

    La boîte de dialogue Save Template s'affiche.

  6. Dans le champ Template Name, affectez un nouveau nom sans le préfixe "STA–". Votre saisie doit être unique.

  7. Cliquez sur Save.

    Le modèle est enregistré.

Enregistrement des paramètres actuels de modèle personnalisé (facultatif)

Cette procédure ne s'applique que si vous disposez de modèles personnalisés. La mise à niveau conserve les modèles personnalisés, mais après la mise à niveau, STA est propriétaire de tous les modèles personnalisés, et leur visibilité est publique.

Suivez cette procédure pour enregistrer les paramètres actuels de propriété et de visibilité de tous les modèles personnalisés afin de les restaurer après la mise à niveau, si nécessaire. Vous pouvez ignorer cette procédure si la propriété et la visibilité des modèles ne sont pas critiques pour votre mise en oeuvre.

  1. Connectez-vous à STA avec un nom d'administrateur.

  2. Sous l'ongletSetup & Administration, sélectionnez Templates Management.

  3. Sélectionnez l'icône Filter et appliquez un filtre pour que l'écran n'affiche que les modèles dont STA n'est pas propriétaire — seuls les modèles personnalisés seront présentés.

    La description de upgrade_filternotsta.png est la suivante
    Description de l'illustration upgrade_filternotsta.png

  4. Enregistrez les paramètres Owner et Public Visibility actuels de chaque modèle personnalisé. Si vous disposez de nombreux modèles, vous pourrez souhaiter effectuer une copie d'écran.

Enregistrement des paramètres de stratégie de rapport exécutif (facultatif)

Cette procédure ne s'applique que si vous disposez de stratégies de rapports exécutifs détenues de manière privée. La mise à niveau préserve les stratégies de rapports exécutifs, mais après la mise à jour, la propriété publique est affectée à toutes les stratégies privées.

Suivez cette procédure pour enregistrer les paramètres actuels de propriété de toutes les stratégies privées afin de les restaurer après la mise à niveau, si nécessaire. Vous pouvez ignorer cette procédure si la propriété de stratégie de rapport exécutif n'est pas critique pour votre mise en oeuvre.

  1. Connectez-vous à STA avec un nom d'administrateur STA.

  2. Sous l'onglet Setup & Administration, sélectionnez Executive Reports Policies.

  3. Sélectionnez l'icône Filter pour que l'écran ne présente que les stratégies dont STA n'est pas propriétaire — seules les stratégies privées s'afficheront.

    La description de upgrade_rptnotsta.png est la suivante
    Description de l'illustration upgrade_rptnotsta.png

  4. Enregistrez le propriétaire actuel du rapport pour chaque stratégie. Si vous disposez de nombreuses stratégies, vous pourrez souhaiter effectuer une copie d'écran.

Tâches de mise à niveau

Prudence:

Seul un administrateur Linux ou STA devra effectuer la mise à niveau. Toutes les tâches sont obligatoires et doivent être effectuées aussi précisément que décrit, dans l'ordre indiqué, sans quoi des pertes de données pourront survenir.

Si vous utilisez la méthode à serveur unique, vous effectuerez ces tâches en ordre séquentiel ; pour plus d'informations, reportez-vous à la copie d'écran Figure 8-1, Présentation de la tâche de mise à niveau avec serveur unique.

Si vous utilisez la méthode de mise à niveau à deux serveur, vous n'effectuerez pas les tâches en ordre séquentiel, et la tâche 6 sera omise, reportez-vous à la copie d'écran Figure 8-2, Présentation de la tâche de mise à niveau avec deux serveurs pour connaitre l'ordre des tâches à effectuer.

Tâche 1: Vidage de l'ancienne base de données STA

Suivez cette procédure pour effectuer un vidage complet de l'ancienne (actuelle) base de données STA.

  1. Suivez les étapes suivantes pour afficher la taille de la base de données STA actuelle.

    1. Connectez-vous à STA avec un nom d'administrateur STA.

    2. Cliquez sur About dans la barre d'état.

    3. Dans la boîte de dialogue About, faites défiler le menu pour afficher la Database Current Size, et enregistrez cette valeur.

  2. Suivez les étapes suivantes pour vérifier que l'emplacement où effectuer le vidage de la base de données dispose de suffisamment d'espace disque.

    1. Ouvrez une session de terminal sur le serveur STA et connectez-vous en tant qu'utilisateur root du système.

    2. Affichez l'espace disponible de la cible du vidage de la base de données, et vérifiez s'il est suffisant pour contenir le fichier de vidage. Par exemple :

      # df -h /dbdumpfiles
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/sta_server-STA_DbVol
                      200G   53G   243G  27% /dbdumpfiles

  3. Arrêtez tous les services STA.

    # STA stop all

  4. Démarrez le service MySQL.

    # service mysql start

  5. Effectuez le vidage de la base de données STA vers un fichier unique. A l'invite, saisissez le mot de passe de l'utilisateur root de base de données.

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql
Enter password: mysql_root_password

    Remarque:

    Le paramètre facultatif –v (pour la sortie détaillée), n'est pas recommandé, car un grand nombre de messages est affiché sur la fenêtre de terminal, et le traitement de commande des grandes bases de données peut se retrouver ralenti de façon significative.

    Dans l'exemple Exemple 8-1, le vidage de la base de données STA 1.0.x s'effectue vers le dossier /dbdumpfiles du serveur STA, et porte le nom de fichier Dec14_dump.sql.

    Exemple 8-1 Vidage de l'ancienne base de données

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dbdumpfiles/Dec14_dump.sql

Enter password: mysql_root_password
...
-- Retrieving view structure for table v_library_complex_io...
...
-- Retrieving view structure for table v_library_summary_averages...
-- It's base table, skipped
...
-- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
...
-- Disconnecting from localhost...

  6. Pour réduire la taille du fichier de vidage d'environ 50 %, compressez le fichier en gzip.

    # cd /path_to_dump_file/
# gzip dump_file_name.sql

Tâche 2 : Transfert du vidage de l'ancienne base de données

Suivez cette procédure pour transférer le vidage compressé de l'ancienne base de données STA vers un serveur de sauvegarde hors de la plateforme, (méthode à serveur unique), ou vers le nouveau serveur STA 2.1.0 (méthode à deux serveurs).

Prudence:

Si vous effectuez une mise à niveau de STA 1.0.x avec la méthode à serveur unique, vous devez sauvegarder la base de données STA sur un autre serveur. Ne sauvegardez pas la base de données sur un système de fichiers sur le serveur STA actuel, car l'installation de Linux 6.x lors de la Tâche 3a : Installation de la nouvelle version de Linux (pour les mises à niveau depuis STA 1.0.x) détruira toutes les données du serveur.

  1. Si ce n'est déjà fait, arrêtez tous les services STA.

    # STA stop all

  2. Effectuez une somme de contrôle avant de transférer le fichier sur le serveur de sauvegarde.

    # cksum dump_file_name.sql.gz

    Le résultat inclut une valeur de somme de contrôle et un calcul d'octets. Enregistrez la valeur de somme de contrôle ; vous l'utiliserez pour vérifier l'intégrité du fichier après le transfert du fichier vers le serveur de sauvegarde.

  3. Transférez le fichier vers le serveur cible à l'aide d'un utilitaire de transfert comme SCP. L'option -p conserve les valeurs d'horodatage.

    # scp -p dump_file_name.sql.gz target_host:/path/

    Dans l'exemple Exemple 8-2, SCP sert à transférer le fichier de vidage compressé de la base de données Dec14_dump.sql.gz vers le dossier /dbdumpfiles de l'hôte de sauvegarde backup1. Le dossier /dbdumpfiles existe déjà sur l'hôte de sauvegarde.

    Exemple 8-2 Transfert de l'ancienne base de données vers le serveur de sauvegarde (méthode à serveur unique)

    # cd /dbdumpfiles
# scp -p Dec14_dump.sql.gz backup1:/dbdumpfiles

    Dans l'exemple Exemple 8-3, SCP sert à transférer le fichier de vidage compressé de la base de données Dec14_dump.sql.gz vers le dossier /dbdumpfiles sur l'hôte STA 2.1.0 sta_new.

    Exemple 8-3 Transfert de l'ancienne base de données vers le nouveau serveur STA (méthode à deux serveurs)

    # cd /dbdumpfiles
# scp -p Dec14_dump.sql.gz sta_new:/dbdumpfiles

  4. Sur le serveur cible, effectuez une somme de contrôle du fichier transféré. Vérifiez que les valeurs de somme de contrôle correspondent.

    # cd /path_to_dump_file/
# cksum dump_file_name.sql.gz

Tâche 3a : Installation de la nouvelle version de Linux (pour les mises à niveau depuis STA 1.0.x)

Cette procédure ne s'applique qu'aux mises à niveau de STA 1.0.x. Installez Linux 6.3 ou ultérieure sur le serveur STA ; pour obtenir des instructions, reportez-vous au chapitre Chapitre 2, Installation de Linux.

Prudence:

Cette activité détruit toutes les données du serveur. Si vous utilisez la méthode à serveur unique, ne suivez cette procédure qu'après avoir effectué les tâches Tâche 1: Vidage de l'ancienne base de données STA et Tâche 2 : Transfert du vidage de l'ancienne base de données.

Tâche 3b : Désinstallation de l'ancienne version de STA (pour les mises à niveau depuis STA 2.0.x)

Cette procédure ne s'applique qu'aux mises à niveau de STA 2.0.x. Désinstaller la version actuelle de STA ; pour obtenir des instructions, reportez-vous aux sections Désinstallation de STA et Vérification de la réussite de la désinstallation..

Prudence:

Cette activité détruit toutes les données STA du serveur. Si vous utilisez la méthode à serveur unique, ne suivez cette procédure qu'après avoir effectué les tâches Tâche 1: Vidage de l'ancienne base de données STA et Tâche 2 : Transfert du vidage de l'ancienne base de données.

Tâche 4: Installation de la nouvelle version de STA

Suivez cette procédure pour installer STA 2.1.0.

  1. Installez STA 2.1.0 ; pour obtenir des instructions, reportez-vous à la section Installation de STA.

  2. Pour vérifier que STA fonctionne correctement et pour terminer la configuration de l'administrateur STA sous WebLogic, connectez-vous à l'application STA.

    L'écran Dashboard est affiché.

    Remarque:

    Le processus de mise à niveau n'étant pas encore terminé, les portlets de tableau de bord affichent le message "No data to display", ce qui est normal. Les données des bibliothèques seront correctement affichées après la mise à niveau de la base de données et la configuration de la nouvelle version de STA.

  3. Déconnectez-vous de STA.

  4. Ouvrez une session de terminal sur le serveur STA et connectez-vous en tant qu'utilisateur root du système.

  5. Arrêtez tous les services STA.

    # STA stop all

  6. Cette étape s'applique uniquement si vous souhaitez que STA contrôle les bibliothèques à l'aide de SNMP v2c (pour plus de détails, reportez-vous à la section Annexe F, Configuration du mode SNMP v2c). Depuis STA 2.0.x, SNMP v2c est activé par défaut. Suivez les étapes suivantes pour confirmer que SNMP V2c est activé.

    1. Passez au répertoire de fichiers de configuration de STA.

      # cd /Oracle_storage_home/Middleware/user_projects/domains/TBI

    2. Affichez le fichier de propriétés de version de SNMP, et vérifiez que le paramètre V2c est défini sur true.

      # cat TbiSnmpVersionSupport.properties
V2c=true
Verbal=false

    3. Si ce n'est pas le cas, reportez-vous à la section Activation du mode SNMP v2c pour STA pour obtenir des instructions pour le modifier.

Tâche 5 : Vidage de la nouvelle base de données STA (facultatif)

Cette procédure est facultative, mais elle est recommandée. Suivez cette procédure pour procéder au vidage de la base de données STA 2.1.0 par sûreté. Si la mise à niveau (Tâche 8 : Mise à niveau de l'ancienne base de données) ne peut pas se terminer, il est possible de restaurer la base de données vide pour récupérer STA 2.1.0 dans un état permettant sa configuration pour l'exécuter comme s'il s'agissait d'une nouvelle installation sans données ; pour obtenir des détails sur le processus de récupération, reportez-vous à la section Récupération d'une mise à niveau de base de données ayant échoué (facultatif).

  1. Ouvrez une session de terminal sur le serveur STA et connectez-vous en tant qu'utilisateur root du système.

  2. Si ce n'est déjà fait, arrêtez tous les services STA.

    # STA stop all

  3. Démarrez le service MySQL.

    # STA start mysql

  4. Créez le fichier de sauvegarde de la base de données. A l'invite, saisissez le mot de passe de l'utilisateur root de base de données.

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql

    Remarque:

    Le paramètre facultatif –v (pour la sortie détaillée), n'est pas recommandé, car un grand nombre de messages est affiché sur la fenêtre de terminal, et le traitement de commande des grandes bases de données peut se retrouver ralenti de façon significative.

    Sous Exemple 8-4, le vidage de la base de données STA 2.1.0 s'effectue vers le dossier /dbdumpfiles du serveur STA avec comme nom de fichier STA_FRESH_INSTALL_BACKUP.sql.

    Exemple 8-4 Vidage de la nouvelle base de données

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb >  /dbdumpfiles/STA_FRESH_INSTALL_BACKUP.sql
Enter password: mysql_root_password
...
-- Retrieving view structure for table v_mdv_request_states...
-- Retrieving view structure for table version_info...
...
-- Disconnecting from localhost...

    Remarque:

    Si vous voyez le message "Can’t connect to local MySQL server", alors le serveur MySQL n'est pas en cours d'exécution. Assurez-vous d'avoir lancé MySQL (Etape 3).

Tâche 6 : Transfert de l'ancienne base de données STA sur le serveur STA

Remarque:

Cette procédure ne s'applique que pour la méthode à serveur unique.

Suivez cette procédure pour transférer la sauvegarde de base de données STA 1.0.x ou STA 2.0.x sur le serveur STA 2.1.0.

  1. Si ce n'est déjà fait, arrêtez tous les services STA.

    # STA stop all

  2. Transfert de la base de données L'option –p activée sur SCP conserve les valeurs d'horodatage.

    # scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path

    Sous Exemple 8-5, SCP sert à transférer le fichier compressé de vidage de la base de données Dec14_dump.sql.gz depuis /dbdumpfiles sur l'hôte backup1 vers le dossier /dbdumpfiles sur le serveur STA 2.1.0.

    Exemple 8-5 Transfert de l'ancienne base de données vers le nouveau serveur STA

    # scp -p backup1:/dbdumpfiles/Dec14_dump.sql.gz /dbdumpfiles

  3. Effectuez une somme de contrôle du fichier transféré. Vérifiez que la valeur de somme de contrôle correspond à la valeur que vous avez reçue dans la Tâche 1: Vidage de l'ancienne base de données STA.

    # cd /path_to_dump_file/
# cksum dump_file_name.sql.gz

Tâche 7 : Traitement et chargement de l'ancienne base de données STA

Suivez cette procédure pour décompresser la base de données STA 1.0.x ou STA 2.0.x, et la rétablir sur le serveur STA 2.1.0. La base de données décompressée peut requérir 10 à 15 fois plus d'espace que la base de données compressée.

  1. Si ce n'est déjà fait, arrêtez tous les services STA.

    # STA stop all

  2. Décompressez le fichier de sauvegarde.

    # gunzip dump_file_name.sql.gz

  3. Suivez les étapes suivantes pour purger la base de données STA de données obsolètes telles que des enregistrements SNMP qui ont déjà été traités ou des enregistrements d'analyse vides.

    Estimation de la durée : Pour STA 1.0.x et STA 2.0.x, jusqu'à une minute par giga-octet de taille d'instantané de base de données décompressée.

    Remarque:

    Un enregistrement permanent de l'activité de la commande purgerecs est enregistré dans la base de données STA. Depuis STA 2.0.x, la purge de la base de données a lieu automatiquement au moment de l'exécution. MySQL Event Scheduler effectue régulièrement des purges d'enregistrements de différentes tables pour modérer l'augmentation de la base de données.

    1. Passez au répertoire des mises à jour de sauvegarde de la base de données STA.

      # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates

    2. Lancez la purge des données.

      # ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/dump_file_name_PURGED.sql

      Remarque:

      Pour obtenir de l'aide avec la commande purgerecs, tapez la commande suivante : 
      # ./purgerecs -h

    Sous Exemple 8-6, l'utilitaire purgerecs traite le fichier de vidage MySQL Dec14_dump.sql dans /dbdumpfiles. La sortie est dirigée vers un nouveau fichier appelé Dec14_dump_PURGED.sql dans /dbdumpfiles. Un point de progression apparaîtra pour tous les 200 enregistrements traités.

    Exemple 8-6 Purge des données obsolètes de l'ancienne sauvegarde de base de données

    # cd /Oracle/StorageTek_Tape_Analytics/db/updates
# ./purgerecs /dbdumpfiles/Dec14_dump.sql /dbdumpfiles/Dec14_dump_PURGED.sql
................................................
          STA v1.0.2, Schema 33.02 
Processed 11,689 lines from '20130711_dump.sql':
------------------------------------------------
snmp_storage_cells........1,614,255
snmp_media................110,205
...
media_summaries...........254
transform_logs............0
================================================
Records Processed:........13,143,283
Records Purged:...........2,857,623
Records Remaining:........10,285,660
Elapsed Time:.............00:00:11

  4. Cette opération est facultative. Déterminez la taille du fichier de la base de données et le temps de traitement.

    Estimation de la durée : Pour STA 1.0.x et STA 2.0.x, jusqu'à trois à dix minutes par giga-octet de taille d'instantané de base de données décompressée.

    # ls -s -h dump_file_name_PURGED.sql

  5. Démarrez le serveur MySQL.

    # STA start mysql

  6. Chargez la base de données STA 1.0.x ou STA 2.0.x. A l'invite, saisissez le mot de passe de l'utilisateur root de base de données. A moins de spécifier l'option -v (détaillée) (non recommandé), vous ne verrez aucune sortie de commande lors de l'exécution du processus.

    Remarque:

    Le paramètre facultatif –v (pour la sortie détaillée), n'est pas recommandé, car un grand nombre de messages est affiché sur la fenêtre de terminal, et le traitement de commande des grandes bases de données peut se retrouver ralenti de façon significative.
    # mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name_PURGED.sql;"
Password: mysql_root_password

    Où :

    • –p — demande le mot de passe root de la base de données établi pendant l'installation de STA.

    • –e — exécute les instructions entre guillemets suivantes :

      • SET SESSION SQL_LOG_BIN=0; — Coupe les connexions binaires inutiles, permettant d'accélérer le chargement.

      • SOURCE /path_to_dump_file/dump_file_name_PURGED.sql — Charge le fichier de vidage dans la base de données.

    Si la commande aboutit, vous revenez à l'invite de commande une fois que le processus se termine.

Tâche 8 : Mise à niveau de l'ancienne base de données

Suivez cette procédure pour mettre à niveau la base de données STA 1.0.x ou STA 2.0.x sur le schéma STA 2.1.0.

Estimation de la durée : Durée approximative, par giga-octet de taille d'instantané de base de donnés décompressée.

  • STA 1.0.x — Jusqu'à cinq minutes par giga-octet

  • STA 2.0.x — Jusqu'à 30 minutes par giga-octet

  1. Si ce n'est déjà fait, arrêtez tous les services STA.

    # STA stop all

  2. Si, lors de l'étapeVérification des prérequis de la mise à niveau, vous avez déterminé que la taille de /tmp n'est pas suffisante pour la mise à niveau, augmentez la taille de /tmp autant que nécessaire.

    Si cette opération n'est pas possible, suivez les étapes suivantes pour définir une variable d'environnement que MySQL utilisera comme emplacement temporaire alternatif :

    1. Créez un emplacement temporaire alternatif et affectez-lui les autorisations d'ouverture. Par exemple :

      # mkdir /dbbackup/tmp
# chmod 777 /dbbackup/tmp

    2. Arrêtez MySQL.

      # STA stop mysql

    3. Modifiez le fichier de configuration MySQL. Par exemple :

      #  vi /etc/my.cnf

    4. Dans la section mysqld du fichier, ajoutez une ligne définissant l'emplacement temporaire alternatif, identifié par la variable tmpdir. Ci-dessous, un exemple du fichier une fois cette ligne ajoutée.

      [mysqld]
#----- mysqld MySQL Server Options -------------------------
 
tmpdir                          = /dbbackup/tmp
server-id                       = 1
...

    5. Redémarrez MySQL.

      # STA start mysql

  3. Passez au répertoire des mises à jour de la base de données.

    # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates

  4. Commencez le script de mise à niveau, et, à l'invite, saisissez le mot de passe de l'utilisateur root de la base de données. Pour des raisons de sécurité, le mot de passe ne s'affiche pas à l'écran.

    # ./upgradedb.sh

    Remarque:

    Vous pouvez effectuer cette étape en tant qu'utilisateur root du système, ou en tant qu'utilisateur du programme d'installation Oracle.

    Ci-dessous, un exemple d'affichage d'écran.

    # ./upgradedb.sh

DB Root Password: 
+-------------------------------------------------------------+
| STA DATABASE UPGRADE                                        |
| Upgrading DB schema from 58.00r0 to 59.00r0                 |
| Started: 2014-12-12 15:14:45                                |
+-------------------------------------------------------------+
STA database is 5.15 GB and contains approximately 12,636,002 records.
Checking if current database v58.00 is a valid upgrade candidate...
...DB v58.00 is a valid upgrade candidate...
+-------------------------------------------------------------+
==> You may ABORT using CTRL-C within 7 seconds
==> .....6.....5.....4.....3.....2.....1
==> CTRL-C disabled!
+-------------------------------------------------------------+
Starting upgrade...

    Lorsque le traitement est terminé, une bannière similaire à celle-ci s'affiche :

    Prudence:

    Attendez de voir cette bannière avant de poursuivre.
    +-------------------------------------------------------------+
| Started.................2014-12-12 15:14:45                 |
| Finished................2014-12-12 17:07:11                 |
| Elapsed Time............01:52:26                            |
| Starting Version........58.00r0                             |
| Final Schema Version....59.00r0                             |
| Schema Release Date.....2014-12-12 11:00:00                 |
| Records (approximate)...12,636,002                          |
+-------------------------------------------------------------+

  5. Si pendant la tâche Tâche 8 : Mise à niveau de l'ancienne base de données, vous avez augmenté la taille de /tmp ou créé un emplacement temporaire alternatif, restaurez-le à sa taille normale et dans son emplacement prévu.

  6. Démarrez tous les services STA.

    # STA start all

  7. Cette opération est facultative. Supprimez le fichier STA_FRESH_INSTALL_BACKUP.sql pour libérer de l'espace disque sur le volume de sauvegarde de la base de données STA.

Tâche 9 : Configuration de la nouvelle version de STA

Suivez ces procédures pour configurer les bibliothèques et STA 2.1.0 pour que STA puisse commencer à contrôler l'activité des bibliothèques.

Mise à jour du destinataire de déroutement STA sur les bibliothèques

Deux nouveaux niveaux de déroutement, 13 (déroutement de test) et 14 (déroutement d'intégrité) ont été introduits avec STA 2.0.x. Suivez les étapes suivantes sur chaque bibliothèque contrôlée pour vous assurer que ces niveaux de déroutement sont inclus dans la définition du destinataire de déroutement STA.

  1. Selon votre chemin de mise à niveau, procédez comme suit :

    • Si vous utilisez la méthode à serveur unique pour mettre à niveau depuis STA 2.0.x, passez à la section Configurez les paramètres SNMP dans STA.

    • Si vous utilisez la méthode à serveur unique pour mettre à niveau de STA 1.0.x, passez à l'étape 2 pour ajouter les nouveaux niveaux de déroutement au destinataire de déroutement STA existant sur chaque bibliothèque contrôlée.

    • Si vous utilisez la méthode de mise à niveau à deux serveurs, passez à l'étape 3 pour ajouter un nouveau destinataire de déroutement STA à chaque bibliothèque contrôlée.

  2. Si vous utilisez la méthode à serveur unique pour mettre à niveau depuis STA 1.0.x, suivez les étapes appropriées au modèle de bibliothèque pour ajouter les nouveaux niveaux de déroutement au destinataire de déroutement STA.

    Sur tous les modèles de bibliothèque, hormis sur le modèle SL150, vous devez supprimer la définition existante et ajouter une nouvelle.

    Toutes les bibliothèques sauf SL150 

    1. Connectez-vous à la CLI de la bibliothèque.

    2. Affichez tous les destinataires de déroutement, et notez le numéro d'indice du destinataire STA.

      snmp listTrapRecipients

    3. Supprimez le destinataire de déroutement STA.

      snmp deleteTrapRecipient id index

      Où :

      • index est le numéro d'indice du destinataire de déroutement STA.

    4. Rajoutez le destinataire de déroutement STA et incluez les nouveaux niveaux de déroutement dans la liste des niveaux de déroutement. Pour obtenir des instructions, reportez-vous à la section Créez le destinataire de déroutement STA SNMP v3. ou Création du destinataire de déroutement SNMP v2c STA sur la bibliothèque.

    Bibliothèques SL150 

    1. Connectez-vous à l'interface utilisateur basée sur un navigateur.

    2. Sous le menu SNMP, sélectionnez SNMP Trap Recipients.

    3. Dans la liste, sélectionnez le destinataire de déroutement STA.

    4. Sélectionnez Modify Trap Recipient.

    5. Ajoutez les nouveaux niveaux de déroutement à la liste des niveaux de déroutement, puis cliquez sur Save.

  3. Si vous utilisez la méthode de mise à niveau à deux serveurs, ajoutez le nouveau serveur STA 2.1.0 comme destinataire de déroutement sur chaque bibliothèque. Voir la section Créez le destinataire de déroutement STA SNMP v3. ou Création du destinataire de déroutement SNMP v2c STA sur la bibliothèque

Configurez les paramètres SNMP dans STA

Suivez ces étapes pour toutes les mises à niveau. Ces étapes sont effectuées dans STA.

  1. Connectez-vous à STA en tant qu'administrateur STA.

  2. Ressaisissez les paramètres de configuration du client SNMP STA à l'aide des valeurs enregistrées avant la mise à niveau ; voir la section Enregistrement de l'utilisateur STA et des paramètres de configuration actuels (facultatif). Ces valeurs doivent correspondre à la configuration des bibliothèques surveillées. Pour obtenir des instructions à ce sujet, reportez-vous à la section Configuration des paramètres client SNMP pour STA.

  3. Pour restaurer la communication SNMP entre STA et les bibliothèques, testez la connexion de chaque bibliothèque surveillée. Pour obtenir des instructions, reportez-vous à la section Test d'une connexion SNMP de bibliothèque.

    Remarque:

    Une fois cette étape réussie, STA commence à recevoir et à traiter les données de chaque bibliothèque contrôlée.

    Vous pourrez remarquer des échanges incomplets sur l'écran Exchanges Overview, qui sont les échanges en cours soit lorsque STA a été arrêté, soir lorsque les connexions aux bibliothèques ont été restaurées. Reportez-vous au guide Guide de l'utilisateur STA pour plus de détails sur les échanges incomplets.

  4. Obtenez les dernières données de configuration SNMP de chaque bibliothèque. Pour obtenir des instructions à ce sujet, reportez-vous à la section Exécution d'une collecte de données manuelle.

Configuration des informations utilisateur et services STA

Suivez ces étapes pour toutes les mises à niveau. Ces étapes s'effectuent sur le serveur STA.

Si vous souhaitez conserver des paramètres de la version STA précédente, utilisez les valeurs enregistrées avant la mise à niveau ; voir l'étape Enregistrement de l'utilisateur STA et des paramètres de configuration actuels (facultatif).

Remarque:

Après la mise à niveau, STA est propriétaire de tous les groupes logiques. La propriété de groupes logiques n'est pas critique pour le fonctionnement de STA, et tout utilisateur STA avec des privilèges d'opérateur ou d'administrateur peut modifier les groupes logiques.

  1. Configurez les utilitaires de service STA Backup et STA Resource Monitor. Pour plus d'informations, reportez-vous à la section Chapitre 7, Configuration des services STA.

  2. Créez des noms d'utilisateur STA et mots de passe ; pour obtenir des instructions, reportez-vous au guide Guide de l'utilisateur STA. Vous pourrez également souhaiter :

    • Prévenir les utilisateurs des nouvelles exigences relatives au mot de passe pour STA 2.1.0.

    • Inviter les utilisateurs à ressaisir leurs préférences personnalisables, le cas échéant.

  3. Si le serveur de messagerie STA requiert une authentification, vous devez saisir le nom d'utilisateur du compte de messagerie et son mot de passe ; pour obtenir des instructions, reportez-vous au guide Guide de l'utilisateur STA.

  4. Restaurez la propriété originale des modèles personnalisés, le cas échéant ; pour obtenir des informations, reportez-vous au guide Guide de l'utilisateur STA.

  5. Restaurez la propriété originale des stratégies de rapports exécutifs, le cas échéant ; pour obtenir des instructions, reportez-vous au guide Guide de l'utilisateur STA.

Mise hors service de l'ancien serveur STA (facultatif)

Cette méthode s'applique uniquement si vous avez utilisé la méthode de mise à niveau à deux serveurs. Vous pouvez utiliser cette procédure après avoir vérifié que le nouveau serveur STA fonctionne comme prévu.

  1. Supprimez l'ancien serveur STA 1.0.x ou STA 2.0.x comme destinataire de déroutement de la configuration SNMP de chaque bibliothèque. Pour obtenir des instructions, reportez-vous au guide Guide de l'utilisateur STA.

  2. Mettez hors service l'ancien serveur STA 1.0.x ou STA 2.0.x.

Récupération d'une mise à niveau de base de données ayant échoué (facultatif)

Prudence:

Suivez cette procédure uniquement sous la direction de votre représentant du support technique Oracle.

Suivez cette procédure uniquement si la mise à niveau de la base de données pendant la tâche Tâche 8 : Mise à niveau de l'ancienne base de données a échoué, et que les essais de répétition de la mise à niveau ont également échoué.

  1. Répétez la tâche Tâche 7 : Traitement et chargement de l'ancienne base de données STA, de l'étape 6, jusqu'à la tâche Tâche 8 : Mise à niveau de l'ancienne base de données.

    Si la mise à niveau échoue à nouveau, il est possible que la base de données se trouve dans un état inconnu ou endommagé, et vous devez restaurer la base de données dans son état d'origine juste après installation. Passez à l'étape suivante.

  2. Supprimez la base de données mise à niveau et endommagée.

    # mysql -uroot -p -e "drop database stadb;"

  3. Passez à l'emplacement de la sauvegarde de la base de données STA et chargez le fichier de vidage de la base de données de la nouvelle installation que vous aviez créé pendant la tâche Tâche 5 : Vidage de la nouvelle base de données STA (facultatif).

    Par exemple :

    # cd /dbbackup
# mysql -uroot -p -e < /home/oracle/STA_FRESH_INSTALL_BACKUP.sql

  4. Effectuez la tâche Tâche 8 : Mise à niveau de l'ancienne base de données.

  5. Configurez STA en tant que nouvelle installation. Pour plus d'informations, reportez-vous aux sections suivantes :