OKM utilise une conception en cluster nécessitant au moins deux KMA.Bas de page 1 . Cette conception permet de réduire le risque d'interruption de la continuité des activités.
En outre, certaines conditions requises de conception et de protection sont en place pour assister la récupération des composants.
La mise en cluster des KMA permet la réplication des entrées de base de données et l'équilibrage des charges de travail. Dans le cas peu probable où un composant serait défaillant, il peut être facilement remplacé et remis en fonctionnement.
Lors de l'élaboration d'une stratégie de chiffrement et d'archivage, il est important de s'assurer que les données essentielles générées sur les sites sont répliquées et archivées hors site. Ce processus est décrit au Chapitre 3, "Récupération des données".
Ce chapitre fournit des informations sur le remplacement des composants dans OKM.
Un KMA unique peut être récupéré sans impact sur le reste du cluster à condition qu'au moins un KMA reste opérationnel. Les sections suivantes traitent des scénarios qui nécessitent la récupération d'un KMA unique.
Les mises à niveau logicielles n'impliquent pas de réparation ou de récupération. Toutefois, un KMA peut parfois être hors service au cours de la mise à niveau.
Une mise à niveau peut être effectuée sans interrompre les agents de chiffrement actifs.
Le nouveau logiciel peut être téléchargé simultanément sur tous les KMA du cluster.
L'activation du nouveau logiciel nécessite une réinitialisation du serveur KMA.
Par conséquent, la réinitialisation des KMA dans le cluster doit être échelonnée de sorte qu'au moins un KMA soit actif à tout moment.
Lorsque chaque KMA revient à un statut en ligne, toute mise à jour de la base de données effectuée lorsque la KMA était hors ligne est répliquée et tous les KMA du cluster sont resynchronisés.
Lorsqu'un KMA est déconnecté du réseau de gestion, par exemple lorsqu'un nouveau logiciel est activé, les KMA restant du cluster continuent de tenter de le contacter et signalent des erreurs de communication dans le journal des événements d'audit.
Les agents continuent de communiquer avec les autres KMA à travers le réseau. Généralement, il s'agit d'autres KMA associés au même réseau de service. Toutefois, les agents pouvant être connectés au réseau de gestion, ils tentent d'abord de travailler avec les KMA dans leur propre site configuré. Cependant, ils contacteront tout KMA joignable au sein du cluster en cas de besoin.
Lorsque le KMA est reconnecté à au réseau, toute mise à jour de la base de données effectuée lorsque le KMA était déconnecté est répliquée et tous les KMA du cluster sont resynchronisés.
En cas de défaillance matérielle, le KMA doit tout d'abord être supprimé du cluster de sorte que les KMA restants ne tentent plus de communiquer avec lui.
Si la console du KMA est toujours accessible, vous pouvez réinitialiser le KMA. L'opération de réinitialisation rétablit les paramètres d'usine par défaut de l'unité. Cette opération propose l'option d'effacement du disque dur du serveur en tant que précaution de sécurité supplémentaire. Le client s'occupe de l'élimination du serveur défaillant.
Un serveur KMA de remplacement est configuré et ajouté au cluster comme décrit dans le document Oracle Key Manager System Installation and Service Manual, Réf. E48395-01.
Une fois le nouveau KMA ajouté au cluster :
La base de données est répliquée.
Les KMA du cluster sont resynchronisés.
Le nouveau KMA devient un membre actif du cluster.
Tableau 2-1 Configuration de composant
|
Nom de compte : |
|||
|
Responsables de la sécurité : |
|||
|
Membres du quorum : |
|||
|
Emplacement du site : |
N/S du KMA : |
Nom du KMA : |
Niveau du microprogramme du KMA : |
|
Adresse IP du KMA : |
Adresse IP du réseau de service : |
||
|
Adresse IP du gestionnaire OKM : |
Adresse IP ELOM/ILOM : |
||
|
NTP|Oui__Non__IP : |
DHCP|Oui__Non__ |
||
|
Passerelle|Oui__Non__IP : |
DNS|Oui__Non__IP : |
||
|
IPv6 Oui__Non__ |
Domaine : |
||
|
Adresse : |
Nom d'hôte : |
||
|
Numéro du KMA : |
Nombre de KMA dans le cluster : |
||
|
Emplacement du KMA : |
Emplacement du gestionnaire OKM : |
||
|
Types de configuration : |
Bibliothèque SL8500 Bibliothèque SL3000 Bibliothèque SL500 Bibliothèque 9310 Bibliothèque L700/1400 |
Types de lecteur de bande : |
Lecteur de bande T10000A Lecteur de bande T10000B Lecteur de bande T10000C Lecteur de bande T10000D Lecteur de bande T9840D Lecteur de bande LTO HP Lecteur de bande LTO IBM |
|
Emplacement du site : |
N/S du KMA : |
Nom du KMA : |
Niveau du microprogramme du KMA : |
|
Adresse IP du KMA : |
Adresse IP du réseau de service : |
||
|
Adresse IP du gestionnaire OKM : |
Adresse IP ELOM/ILOM : |
||
|
NTP|Oui__Non__IP : |
DHCP|Oui__Non__ |
||
|
Passerelle|Oui__Non__IP : |
DNS|Oui__Non__IP : |
||
|
IPv6 Oui__Non__ |
Domaine : |
||
|
Adresse : |
Nom d'hôte : |
||
|
Numéro du KMA : |
Nombre de KMA dans le cluster : |
||
|
Emplacement du KMA : |
Emplacement du gestionnaire OKM : |
||
|
Types de configuration : |
Bibliothèque SL8500 Bibliothèque SL3000 Bibliothèque SL500 Bibliothèque 9310 Bibliothèque L700/1400 |
Types de lecteur de bande : |
Lecteur de bande T10000A Lecteur de bande T10000B Lecteur de bande T10000C Lecteur de bande T10000D Lecteur de bande T9840D Lecteur de bande LTO HP Lecteur de bande LTO IBM |
Légende de note de bas de page
Note de bas de page 1: Serveurs multiples : les exceptions à cette configuration standard doivent être mises en oeuvre avec l'approbation des services de support global et d'ingénierie d'OKM.