Comment se préparer à un Real Application Clusters installer dans Oracle 12c

Chaque OS a sa propre configuration pour un Real Application Cluster (RAC) installer à utiliser avec des bases de données Oracle 12c. Il est pratiquement impossible de tout couvrir, mais il ya des bases qui peuvent être couverts pour vous aider à démarrer.

Cependant, il ya quelques morceaux de conseils à offrir:

• Lire attentivement l'installation de l'infrastructure Oracle Grid et le guide de déploiement pour votre OS spécifique. Ce qui vaut sur un OS peut pas voler sur un autre.

• Soyez cohérent sur tous les nœuds pour nommer les utilisateurs, les groupes, les identifiants de groupe et ID utilisateur. Assurez-vous que le même utilisateur possède tous les composants logiciels Oracle.

  Par exemple, sous Linux, oracle est typiquement un compte qui possède l'installation du logiciel Oracle. Créer cet utilisateur exactement de la même façon que vous allez à tous les nœuds. Linux a au moins deux groupes de systèmes d'exploitation pour Oracle (dba et oinstall). Ceux-ci doivent être identiques.

  Pour les utilisateurs et les groupes, cela vaut pour l'ID de groupe (gid) et ID utilisateur (UID) ainsi. Le gid et uid conserver les autorisations au niveau de l'OS. Si ils ne sont pas identiques entre les nœuds, les autorisations ne seront pas correctement entretenus, et le cluster ne fonctionneront pas.

• Mettre en place le fichier hosts correctement. Cela vaut pour toutes les installations de l'ACFC. Le logiciel de clustering utilise le fichier hosts pour installer le logiciel et de maintenir des communications. Le serveur de nom de domaine, ou DNS, ne se substitue pas à cela. Vous pouvez ajouter la configuration de l'hôte du DNS si vous voulez, mais assurez-vous le fichier hosts est correctement configuré.

  Voici un exemple de ce qu'est un fichier RAC hôte à deux nœuds peut ressembler à:

  127.0.0.1 localhost.localdomain localhost192.168.100.11 node1-priv.perptech.com node1-priv # node1 node2 private192.168.100.12 node2-priv.perptech.com-priv # node2 private192.168.200.11 node1.perptech.com node1 # node1 node2 public192.168.200.12 node2.perptech.com # node2 public192.168.200.21 node1-vip.perptech.com node1-vip # node1 node2 virtual192.168.200.22 node2-vip.perptech.com-vip # node2 virtuel

• 
  
  
  
  

  Chaque nœud se connecte à un autre à travers un privé réseau à grande vitesse (interconnexion de cluster).

• La public IP utilisée pour toutes les communications de l'utilisateur vers les noeuds ne soit pas lié à l'interconnexion.

• Chaque nœud de cluster a également un virtuel Adresse IP qui se lie à la carte réseau public. Si un nœud échoue, l'adresse IP de l'noeud défaillant peut être réaffectée à un autre nœud afin que les applications puissent garder accéder à la base à travers la même adresse IP.

  Comme d'Oracle 11gR2, cela se fait à l'aide d'un nouveau composant de réseau de cluster appelé un SCAN. SCAN signifie unique accès client-nom. Trois personnalités sont affectés sur le réseau à un nom de balayage (généralement le nom de votre cluster), et que le nom d'un SCAN est ensuite utilisé pour toutes les communications. Les trois personnalités peuvent flotter à travers les nœuds pour fournir des capacités de connectivité et de basculement constants.

ORACLE_BASE = / u01 / app / oracleORA_CRS_HOME = / u01 / app / grille

Les fonctions de communication et de copie sont pour l'installation de logiciels et de correctifs. Ils ne sont pas tenus pour RAC au travail après le fait, si l'ouverture de ces choses est contre les politiques de sécurité de l'entreprise.

Oracle Real Application 12c Application Clusters pour la haute disponibilité

RAC aide à haute disponibilité en fournissant redondance dans votre environnement - en particulier, les instances Oracle redondants. Un exemple dans un environnement multi-instance peut être enlevé pour OS, matériel, ou de maintenance de logiciels Oracle sans perturber l'application.

Cependant, assurez-vous que vos attentes rencontrent ce RAC peut fournir:

• RAC ne couvre pas tous les points de défaillance. Il contribue certainement se durcir contre la défaillance d'un nœud et l'échec de l'instance. Malheureusement, il ne peut pas aider avec SAN, interconnexion, ou d'une erreur de l'utilisateur.

• RAC est généralement pas considéré comme une solution de protection en cas de catastrophe. Si votre site entier est compromise par le vent, le feu, ou de l'eau, RAC va avec elle.

Real Application Clusters et Oracle 12c étendues

Les nouveaux développements se produisent dans un mouvement appelé RAC prolongée. Cette solution de RAC peut protéger contre la perte totale du site tout en offrant toutes les autres caractéristiques de l'ACFC. Comme les vitesses de transmission du réseau augmentent au fil du temps, certaines personnes pensent que le RAC est possible avec les instances dans des endroits éloignés.

Cette configuration nécessite haut débit SAN en miroir et un support de transmission de réseau appelé fibre noire. Fibre noire est, une connexion directe privée entre deux sites distants qui peuvent gérer de multiples transmissions réseau à la fois sur le même câble en utilisant différentes fréquences de lumière.

Au moment de presse, RAC prolongée semble avoir des limites de distance. Le plus éloignés des sites, plus le temps de latence. Latence se transforme en une dégradation des performances de cluster. Nous avons été incapables de trouver toute la documentation définitive sur les limites de distance. La dégradation semble tenir fortement dans votre type de connexion. Certains sites utilisent des répéteurs pour étendre encore plus loin.

En attendant, si vous avez besoin d'un site distant configurée pour la reprise après sinistre, vous pouvez envisager de Data Guard. Il peut offrir un grand nombre de fonctionnalités qui étendent le RAC fait, mais à une fraction du coût réel sans limite de distance.