Consolidation Haute Disponibilité et Qualité de Service Charles-emmanuel Frances Consultant Vente France Grid Economics!!! HR Base de données Haute Dispo CRM ERP Middleware Examiner et Limiter les dépenses du SI Devenir plus efficace pour réduire les frais d'exploitation Fournir un meilleur service, une meilleure disponibilité et performance du système.
Approche IT Traditionnelle Une application = n Serveurs dédiés Systèmes Cloisonnés Chaque infrastructure dimensionnée pour un pic de charge Inconvénients Evolutivité faible Solution onéreuse La puissance de peut pas être partagée Middleware Database Storage Application N = x Serveurs dédiés Haute Disponibilité traditionnelle Chère, Non utilisée, Redondante Serveur de secours non utilisé EMC SRDF BMC SQL Backtrack Volume Manager
Oracle Maximum Availability Architecture Consolidation et Haute Disponibilité Backups sécurisés (Cloud ou tape) Real Application Clusters Data Guard Recovery Area Automatic Storage Management Pas de HA pour les Single Instance Avant la 11g Release 2 Arrêt brutal de l instance de base de données Redémarrage manuel des process Oracle en tâche de fond Redémarrage manuel de l instance Temps important pour basculer sur l instance Dataguard Difficulté de scripter des redémarrage automatiques sans risque d erreur Tenir compte des dépendances est compliqué
Oracle Restart pour les SI en 11.2 Process des SI enregistrés dans le CRS Surveillance de l état de santé des processus par le processus CRSD Redémarrage automatique des ressources sans intervention humaine Tient compte des relations et dépendances parmis les composants de la base de données Fait la différence entre un shutdown (normal) et un crash RAC et ses composants Virtualisation des Ressources Scalabilité Haute Performance Haute Disponibilité Transparent pour les applications Gestion flexible de la charge Oracle Clusterware Optimisation des coûts Cache des données partagé Interconnect ASM
Oracle Database 11g Release 2 Oracle RAC One App Servers DW RAC ONE RAC ONE A RAC ONE A& B B RAC ONE C RAC ONE D Technologie Oracle RAC adaptée aux instances uniques de base de données Migration live d instance parmis les serveurs d un Grid Support du Rolling patches Technologie de Cluster Failover pour la haute disponibilité Migration à chaud vers Oracle RAC Déploiement Standardisé parmi toutes les bases Oracle Supporte un déploiement physique et logique 2009 Oracle Corporation Proprietary and Confidential OMotion OMotion transfert une instance RAC-One d un serveur à un autre sans arrêt de service. Cas d utilisation Répartition des instances sur les différents serveurs Maintenance et application de patch Serveur/Système d Exploitation Oracle fournit les scripts nécessaires à cette migration Les services de base de données sont actifs sur un seul noeud à un instant donné. Les instances déplacées effectuent un Shutdown Transactional quand les services ont été déplacés Un maximum de 30 minutes est alloué aux connections pour migrer vers la nouvelle instance Support du Rolling Patch
Oracle RAC-One Deployment Server A Server B Server C RAC1 RAC1 RAC1 RAC1 RAC1 Common Shared Storage Single Cluster OMotion Client Connections RAC1 RAC1 RAC1 RAC1 RAC1 RAC1 Common Shared Storage Single Cluster
L Evolution du Grid Diminuer les coûts de déploiement Oracle RAC pour le HA faire baisser les coûts du HA Oracle RAC pour le Scale out faire baisser les coûts de la scalabilité GRID pour les bases de données Faire baisser le coûts des Infra Posséder le juste utilisé Consolidation du stockage Gestion efficace (base partagée) EM RAC RAC RAC EM RAC RAC RAC Grid pour le Datacenter Faire baisser les coûts de déploiement Coûts d acquisition Coûts d exploitation EM AS AS AS AS AS AS AS RAC RAC RAC RAC RAC RAC RAC EM RAC RAC RAC RAC RAC RAC RAC RAC RAC RAC RAC RAC EM RAC RAC Infrastructure dédiée Infrastructure partagée Shared Cluster Shared Database Shared Storage Infrastructure standardisée Les Enjeux avant la 11g R2 1. Utilisation des ressources matérielle insufisante 2. Le nombre de Noeuds par cluster RAC augmente régulièrement 3. Clusters orientés base de données 4. Difficulté pour déployer des application tiers sur le clusterware App B App C Protégée App A Protégée Resta Resta rt rt Failov Failov er er App D Resta rt Failov er En 11gR2, nous disposons De Pool de serveurs D une gestion basée sur des règles Nouveau type de clusterware
Deux manières de Gérer le RAC Gestion par l administrateur Emplacement des bases et publication des services gérés manuellement au sein du cluster Utilisation d un «Pool» de serveurs nommé «GENERIC» Gestion automatique par les règles On définit les ressources nécessaires pour répondre à la charge Le nombre d instances nécessaire est démarré automatiquement «Pool» de serveurs de bases de données «Pool» spécifique pour les bases de données Oracle Les serveurs ne peuvent être que dans un «pool» à un instant donné Créé par le Database Assistant. MAX= Nombre d instances MIN = 0 (par défaut) IMPORTANCE = 0 (par défaut) Le pool est géré par l utilitaire srvctl ou Enteprise Manager
Gestion des Services et des «pool» Les différents «Pool» de serveurs GENERIC Server Pool (Gestion par l administrateur) Database Server Pool Free Server Pool Les services dans une gestion par les «pool» Un Service est attaché à un et un seul «pool» de serveurs UNIFORM : Publié sur toutes les instances du «pool» SINGLETON : Publié sur une seule instance du «pool» Allocation des serveurs et Reconfiguration Les serveurs sont affectés dans l ordre suivant «GENERIC Server Pool» «Database Server Pool» «Free Server Pool» Utilisation des MIN, MAX et IMPORTANCE des «Pool» Pour l allocation des serveurs Pour la reconfiguration du cluster
Exemple d Allocation des serveurs Cluster avec 6 noeuds PRODDB server pool pour la base prod (min 0, max 3, Imp 2) Services OLTP uniform, BATCH - singleton EMAIL server pool pour la base email (min 0, max 3, Imp 2) Service EMAIL - uniform ora.proddb ora.email Reconfiguration du Cluster Reconfiguration Depuis le Pool Free Depuis un Pool serveur de moindre importance Depuis un Pool serveur d égal importance au dessus de son MIN Pool HR Pool Sales Restart Failover Restart Failover Restart Failover Restart Failover Restart Failover Pool Serveur HR : Pool Serveur Sales : MIN=3 MAX=4 MIN=1 MAX=2 Importance = 5 Importance = 3
Reconfiguration du Cluster Reconfiguration Depuis le Pool Free Depuis un Pool serveur de moindre importance Depuis un Pool serveur d égal importance au dessus de son MIN HR Pool Sales Pool Restart Failover Restart Failover Restart Failover Restart Failover Pool Serveur HR : Pool Serveur Sales : MIN=3 MAX=4 MIN=1 MAX=2 Importance = 5 Importance = 3 Grid Plug And Play (GPnP) : Les Enjeux Problématique liée à la Consolidation : Evolution rapide de l infrastructure Grid Plug And Play (GPnP) GPnP : La Machine du Grid Faciliter l installation et la configuration du cluster Faciliter l extension dynamique du cluster GPnP : Les clients du Grid Faciliter la mise à jour des clients DNS XML
GPnP : Configuration du Grid Plus de Configuration statique liée à un noeud Informations du Cluster dans un profil XML Nom du Cluster Informations réseau (Public et Interconnect) Information Stockage (OCR, Voting, ASM) Fichier géré, sécurisé et répliqué par le process GPnP Automatisation lors de l ajout de serveurs Images, Boot, mise à jour du profil Révolution pour les Administrateurs SID dynamiques, Répertoires des LOG, scripts à adapter GPnP : Résolution de Nom Besoin de résoudre Depuis le Grid vers l extérieur (Inside/Outside) Au sein des machines du Grid (Inside/Inside) De l extérieur vers la machine du Grid (Outside/Inside) La solution Oracle Inside/Outside : Serveur DNS classique Inside/Inside : Multicast DNS (mdns) Outside/Inside : Grid Name Service (GNS)
Résolution de nom MultiCast (mdns) Résolution à l intérieur du Grid Gethostbyname Interface publique en DHCP Interface Privée en DHCP ou Auto-IP (169.254.x.y) Noeud 4? Noeud 4? Noeud1 Nœud 2 Noeud 4? 138.2.145.58 Nœud 3 Nœud 4 Grid Naming Service (GNS) Passerelle DNS vers le mdns Permet aux clients de résoudre les noms des serveurs du Cluster sans maintenance DNS «moncluster.mondomain.com» doit être résolu au sein serveur DNS. «noeud1.moncluster.mondomain.com» doit être résolu au sein du cluster par le mdns Permet l utilisation de DHCP pour les nœuds du RAC.
Grid Naming Service (GNS) résolution à l extérieur du Grid DHCP server Vip Dynamiques 1. Demande de résolution host01.cluster.example.com 2. DNS délègue la transfert vers l IP statique du GNS. 3. GNS résout la demande ou utilise mdns 4. Réponse retournée au client. 2009 Oracle Corporation Proprietary and Confidential Single Client Access Name (SCAN) Gérer les Address List dans les chaines de connection n est plus envisageable Réduction de la complexité de configuration coté client et serveur Le client possède un nom unique qui après résolution via GNS ou DNS le dirige vers l adresse IP du SCAN (SCAN VIP)
SCAN Découverte du Listener //<scan_name>[:<scan_port>]/<service_name> 3 listener SCAN sur 3 Vips Approche Oracle pour la gestion du QoS Définition et mise en œuvre Classification et Mesure Evaluation et Reporting Architecture Pilotée par une stratégie WLM Analyse et Recommandation Implémentation et Contrôle
Oracle Maximum Availability Architecture Eliminer les coûts des arrêts prévus Annuler les erreurs humaines Upgrades à Chaud Patching Online Ajout/Retrait de Processeurs Redéfinition et Réorganisation de tables Ajout/Suppression d éléments de stockage Tests en production à chaud Oracle Maximum Availability Architecture Real Application Clusters Active Data Guard Data Guard Automatic Storage Management Snapshot Standby
Oracle Database 11g Release 1 Evolutions de Dataguard Active Data Guard Base de données de secours en Recovery et lecture en même temps Data Guard Utilisation du réseau Compression lors de l envoi des journaux de transaction dans le cas de la Résolution de Gap Snapshot Standby La base de données de secours utilisée en lecture-ecriture Tests de charge, mise en place de nouvelles fonctionnalités Fast Start Failover (bascule automatique) Oracle Database 11g Release 2 Evolutions de Dataguard Active Data Guard Qualité de service SLA sur les requêtes en lecture sur la base de secours (de zéro à n secondes) Data Guard Utilisation du réseau Compression au fil de l eau des informations de journalisation (WAN) Evènements FAN (Fast Application Notification) au FAILOVER et SWITCHOVER
MAA - quoiqu il arrive!! Modifications logicielles planifiées et à chaud Pannes matérielles/maintenance Matérielle et OS RAC, bases de secours (physiques et logiques) Modification des objets de base de données à chaud Upgrade de base de données à chaud RAC, Base de secours logique Oracle Streams Migration applicative à chaud Edition-Based redefinition Maintenance Applicative à chaud Online Table Redefinition Online Index Rebuild Oracle Application Upgrade Edition-based redefinition Nouvelles fonctionnalités révolutionnaires : edition editioning view crossedition trigger Les modifications du Code sont installés dans une zone nouvelle Edition privée Les modifications sur les données sont effectuées uniquement sur les nouvelles colonnes ou tables (nouvelle Edition) editioning view : Exposition des versions contenant chacune une projection privée des objets de base de données crossedition trigger : Propage les modifications des données de l ancienne version vers une nouvelle version (nouvelles colonnes) et vice-versa (Hot- Rollover)
For More Information http://search.oracle.com HA / MAA or oracle.com/ha Questions