vendredi nov. 04, 2011

Les Raisons d'Installer ASR (3/3)

Pour clore la semaine et cette série sur les raisons d'utiliser ASR, le point abordé sera l'ouverture d'appel automatique.

Le nom même, Auto Service Request, suggère que l'avantage numéro 1 d'activer ASR sera une ouverture d'appel sans passer par le standard téléphonique et son IVR, ni se connecter sur le portail MOS : alors, promesse tenue ?

Comme nous l'avons vu dans les 2 précédents billets (1,2), ASR demande une petite préparation, un effort à faire une fois pour toutes, ensuite, ASR va se mettre en veille, à l'écoute des éventuelles alarmes de détection de pannes.

Voyons en détail comment cela se passe :


  • l'ILOM, le XSCF ou FMA détecte une panne et envoie une trap SNMP (FMA Solaris 11 va changer ce mode de transport) au serveur où est installé ASR, communement appelé l'asr manager.
  • le logiciel ASR va utiliser un jeu de règles, mis à jour régulièrement et automatiquement, pour décider s'il y a lieu d'ouvrir un SR ou pas
  • si oui, l'asr manager "remonte" l'alarme ainsi que l'identifiant de la machine impactée vers le serveur approprié chez Oracle.
  • après vérification des droits au support, un SR est ouvert dans MOS et le numéro est renvoyé à l'asr manager en accusé de réception de la demande.
  • ultime étape optionnelle, l'asr manager envoie une trap snmp à la console de monitoring d'entreprise.

Une fois ouvert, le SR va suivre exactement le même circuit qu'un autre SR ouvert par téléphone ou par le portail MOS.

Promesse tenue !

lundi oct. 31, 2011

ASR, Approche Unifiée d'Ouverture de SR.

ASR est une approche unifiée pour l'ouverture automatique de SR, que les alarmes viennent d'un SDP, d'un CAM, d'un Unified Storage ou d'un ASR System, le cas des Exadata se confondant avec ASR system.

L'infrastructure d'ASR canalise et concentre toutes les demandes d'ouverture d'appel, quelle qu'en soit l'origine.

Ceci explique que dans les 4 cas cités, la mise en oeuvre se ressemble, avec 4 moments distincts :


  • l'enregistrement de l'instance responsable de contacter Oracle

    • dans le cas d'ASR System, c'est la commande asr register
    • dans les autres cas, un formulaire est dédié à cette enregistrement.

  • l'activation d'un équipement

    • avec ASR System, c'est la commande asr activate_asset
    • dans les autres cas, il y a une case à cocher par équipement pour autoriser la remontée des alarmes

      c'est sur cette demande d'activation qui est traitée par l'infrastructure qu'une première validation de l'accès au support (contrat ou garantie) est pratiquée.

  • l'association d'un contact, d'une liste de diffusion et la validation d'ASR au niveau de MOS (My Oracle Support).

    • cette partie est identique dans tous les cas, et elle est indispensable au fonctionnement normal d'ASR. Le contact indiqué ici est un compte d'utilisateur MOS et sera utilisé comme premier contact lors de l'ouverture de SR.

  • la remontée d'alarme et l'ouverture de SR

    • encore une phase identique dans toutes les installations d'ASR, où un process de validation puis d'ouverture de SR est déclanché.

lundi oct. 24, 2011

La version 3.4 d'ASR System

La version 3.4 d'ASR system est maintenant disponible au téléchargement à partir de http://www.oracle.com .

Pour être sûr d'accéder à la dernière version du logiciel, une fois logué sur My Oracle Support(MOS http://support.oracle.com ) , allez sur le document de référence "Oracle Auto Service Request knowledge document" (ID 1185493.1) (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=SYSTEMDOC&id=1185493.1).

En résumé, les versions courantes des logiciels liés à ASR sont :


  • Oracle Auto Service Request Release 3.4
  • Oracle Automated Service Manager Release 1.3.1
  • Oracle Services Tools Bundle Release 6.2 (Solaris) / Sun Service Tag 1.1.5 (OEL)

Cette version 3.4 apporte les améliorations suivantes :

  • des améliorations au niveau du contenu du mail envoyé lorsqu'un Draft SR(1) est créé.
  • une mise à jour de la commande ./asr report avec des instructions sur la détermination du status ASR de vos équipements.
  • une amélioration sur la liste des contacts notifiés lorsque l'ouverture d'un SR n'aboutit pas.

Cette version 3.4 corrige aussi 2 problèmes liés à l'upgrade d'ASR :

  • un parc avec un status Active - No Heartbeat(2) reste dans cet état même après une upgrade du logiciel et des envois de heartbeat.
  • un parc avec un status Pending(3), donc n'envoyant pas de heartbeat, se retrouve de manière erronée en Active – No Heartbeat.

(1) un Draft SR est ouvert lorsque la faute matérielle ne peut être suffisamment avérée par le message d'erreur remonté. Une vérification humaine s'impose et si besoin, il suffit de valider le Draft SR correspondant.
(2) status "Active - no heartbeat" : un asr manager envoie un heartbeat toutes les 12 heures, et après 3 ratés, l'asr manager et tout le parc associé est déclaré active - no heartbeat. Cette situation demande une attention particulière pour vérifier si seulement le heartbeat ne passe plus ou si la connexion avec le transport vers Oracle est perdue.
(3) status Pending : après avoir activé un équipement avec la commande asr activate_asset, vous devez vérifier les informations de contact pour cette machine dans MOS et valider la fonctionnalité ASR.

About

MOS, ASR, SDP, CAM pour la partie Connected Services et Beehive, UCM, WebCenter pour Social Networking au sens large.

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today