lundi déc. 02, 2013

Gérer vos Service Request (les bonnes pratiques MOS)

Vous voulez connaitre les bonnes pratiques My Oracle Support (MOS) pour gérer de façon optimale vos "Service Request" (SR), comment éviter les délais inutiles, comment accélérer les résolutions ?

[Read More]

mardi août 20, 2013

Oracle Sun System Analysis (les bonnes pratiques MOS)

Oracle Sun System Analysis (OSSA) est un service web qui propose des rapports détaillés concernant vos systèmes Solaris. Ce service propose deux types de rapports :

  • Le rapport "Mission Critical", qui inclue
    • les alertes de sécurité, perte de données et disponibilité,
    • les composants en défaut,
    • les patches sécurité manquant,
    • les niveaux des firmwares,
    • des recommendations de bonnes pratiques.

  • Le rapport "Operational Risk Index" (ORI)
    Chaque risque identifié sur votre Solaris de voit attribué une sévérité, ce qui permet de calculer un indexe de risque, l'ORI. La valeur de cet ORI vous permet d'avoir une vue globale du niveau de patches, et des risques d'indisponibilité et de perte de données encourus.

[Read More]

vendredi juil. 26, 2013

Déléguer la gestion des Assets dans MOS pour ASR

Ce nouveau rôle permet de déléguer les opérations liées à ASR dans MOS, sans pour autant déléguer la gestion des utilisateurs.

[Read More]

vendredi mai 04, 2012

Mise à Jour de documents ASR

(traduit de l'article de Wayne Seltzer sur la communauté MOS ASR)

Les 2 documents qui ont été mis à jour sont :


Ces documents sont disponibles sur le site http://oracle.com/asr >> Documentation.

Cliquez sur l'onglet "Learn More" pour accéder au document ASR Overview Presentation.

lundi nov. 07, 2011

ASR et CAM

Après quelques billets à propos d'ASR pour les serveurs, je voudrais parler d'ASR pour les équipements de stockage qui peuvent être administrés avec CAM.

[Read More]

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 !

jeudi nov. 03, 2011

Les Raisons d'Installer ASR (2/3)

Après le support readiness, abordé dans un billet précédent, la deuxième raison d'installer ASR, mis à part le fait que ce n'est pas gratuit mais inclu dans les contrats de support et la garantie, donc ne pas l'activer serait ne pas utiliser ce que l'on a acheté, la deuxième raison est la détection des pannes.

En réalité, ASR en soit ne modifie pas les serveurs du parc, il ne fait qu'exploiter les mécanismes intégrés aux system processors (ILOM, XSCF) et à Solaris 10.

Mais, le résultat avec ASR, c'est que les détections de pannes ne resteront pas ignorées, mais au contraire, serviront à garder l'ensemble des serveurs dans le meilleur état de fonctionnement possible, prévenant les temps d'arrêt de production.

Le conseil qui en découle est simple et fort : si vos serveurs ou autres équipements homologués pour ASR, couverts par un contrat de support Oracle ou une garantie, n'hésitez pas et vérifiez que vous avez bien activé ASR.

Vous éviterez très sûrement toute situation délicate qui aurait dérivée d'une panne non prise en compte immédiatement après son apparition.

mercredi nov. 02, 2011

Annonces ASR à OOW

Quelques annonces faites lors du dernier Oracle Open World à San Francisco ont concerné plus ou moins directement ASR.

Au cours de la Simplify Server Administration with Virtualization and Ops Center Manager Session, il a été présenté que Ops Center, MOS et ASR seront plus intégrés : il y aura plus d'automatisation dans la mise en oeuvre.

Pour MOS, une fonction de découverte automatisée des CSIs rendra plus facile l'interaction avec le portail du support.

Pour ASR, OpsCenter servira d'asr manager et offrira des possibilités de configuration à distance des équipements.

Le message ASR a été aussi montré explicitement lors de la session : Best Practices for Supporting Sun Server and Storage Systems Session.

Tout ceci devrait faciliter le déploiement et favoriser une encore plus grande adoption d'ASR.

mardi nov. 01, 2011

Les Raisons d'Installer ASR (1/3)

Ce billet est le premier d'une série de 3 sur les raisons d'installer et d'activer ASR (Auto Service Request).

Le premier service offert par ASR est la préparation de l'accès au service : Support Readiness en anglais.

En effet, lorsque vous activez un équipement de votre parc :


  • un serveur avec ASR System,
  • un serveur de fichier de la gamme Unified Storage Server (S7000)
  • ou un tiroir de disques administré avec CAM,
  • etc

vous devez valider ASR dans MOS (My Oracle Support).

La première étape, si ce n'est déjà fait, sera de créer votre compte pour MOS, et en fonction de la taille de votre organisation, vérifier que vos collaborateurs concernés par le support, ont aussi un compte sur MOS.

Ensuite, il faudra vous assurer que vous êtes administrateur (CUA Customer User Administrator dans le jargon de MOS), du SI Support Identifier (ou CSI Customer Support Identifier) associé au support de votre équipement.

Si vous ne le connaissez pas, en allant dans MOS, dans l'onglet Settings, en sélectionnant Account & Priviledges, en cliquant sur le bouton request access, vous aurez l'option de faire une recherche basée sur le numéro de série, et le nom exact de client associé au CSI. Ceci n'est pas toujours évident : n'hésitez pas à faire usage du lien Contact us pour placer un SR non-technique et demander de l'aide, ou utilisez la communauté ASR en ligne, nous ferons tout pour vous aider également.

Si vous êtes déjà contact du CSI mais pas administrateur, vous devrez demander à la personne ayant ce rôle, soit de vous accorder les droits d'administration (il faut toujours qu'il y ait plusieurs CUA par CSI), soit lui demander de valider ASR.

Je vous renvoie à un billet précédent sur la manière d'associer un contact et valider ASR dans MOS.

Une fois, cette partie administrative terminée, vous êtes sûrs de :


  • savoir trouver votre machine dans MOS
  • que cette machine est bien couverte par un contrat de support ou une garantie
  • que ASR pourra ouvrir un SR en cas de détection de panne.

Il est prudent de bien préparer l'accès au support afin d'éviter tout problème si vous deviez appeler Oracle en cas de pépin, et pour cela, il est important d'activer ASR.

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é.

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