Un nombre considérable d'applications d'entreprise et de systèmes de virtualisation disposent de leurs propres mécanismes pour créer des solutions tolérantes aux pannes. Plus précisément, Oracle RAC (Oracle Real Application Cluster) est un cluster de deux serveurs de base de données Oracle ou plus travaillant ensemble pour équilibrer la charge et fournir une tolérance aux pannes au niveau serveur/application. Pour travailler dans ce mode, vous avez besoin d'un stockage partagé, qui est généralement un système de stockage.
Comme nous l'avons déjà évoqué dans l'un de nos , le système de stockage lui-même, malgré la présence de composants dupliqués (y compris des contrôleurs), présente encore des points de défaillance - principalement sous la forme d'un seul ensemble de données. Par conséquent, pour créer une solution Oracle avec des exigences de fiabilité accrues, le schéma « N serveurs - un système de stockage » doit être compliqué.
Bien entendu, nous devons d’abord décider contre quels risques nous essayons de nous assurer. Dans cet article, nous n’aborderons pas la protection contre des menaces telles que « une météorite est arrivée ». La création d’une solution de reprise après sinistre géographiquement dispersée restera donc le sujet de l’un des articles suivants. Nous examinerons ici la solution de reprise après sinistre dite Cross-Rack, lorsque la protection est construite au niveau des armoires de serveurs. Les armoires elles-mêmes peuvent être situées dans la même pièce ou dans des pièces différentes, mais généralement dans le même bâtiment.
Ces armoires doivent contenir l'ensemble des équipements et logiciels nécessaires qui permettront le fonctionnement des bases de données Oracle quel que soit l'état du « voisin ». En d’autres termes, grâce à la solution de reprise après sinistre Cross-Rack, nous éliminons les risques de panne :
- Serveurs d'applications Oracle
- Systèmes de stockage
- Systèmes de commutation
- Panne totale de tous les équipements de l'armoire :
- Refus de pouvoir
- Panne du système de refroidissement
- Facteurs externes (humains, nature, etc.)
La duplication des serveurs Oracle implique le principe même de fonctionnement d'Oracle RAC et est mise en œuvre au travers d'une application. La duplication des installations de commutation ne pose pas non plus de problème. Mais avec la duplication du système de stockage, tout n'est pas si simple.
L'option la plus simple est la réplication des données du système de stockage principal vers celui de sauvegarde. Synchrone ou asynchrone, selon les capacités du système de stockage. Avec la réplication asynchrone, se pose immédiatement la question d’assurer la cohérence des données par rapport à Oracle. Mais même s'il existe une intégration logicielle avec l'application, dans tous les cas, en cas de panne sur le système de stockage principal, une intervention manuelle des administrateurs sera nécessaire pour basculer le cluster vers le stockage de sauvegarde.
Une option plus complexe consiste à utiliser des « virtualiseurs » de stockage logiciels et/ou matériels qui élimineront les problèmes de cohérence et les interventions manuelles. Mais la complexité du déploiement et de l'administration ultérieure, ainsi que le coût très indécent de telles solutions, en effraient plus d'un.
La solution de baie AccelStor NeoSapphire™ All Flash est parfaite pour des scénarios tels que la reprise après sinistre entre racks. en utilisant l'architecture Shared-Nothing. Ce modèle est un système de stockage à deux nœuds qui utilise la technologie propriétaire FlexiRemap® pour fonctionner avec des lecteurs flash. Grâce à NeoSapphire™ H710 est capable de fournir des performances allant jusqu'à 600 4 IOPS en écriture aléatoire en 1K et plus de 4 million d'IOPS en lecture aléatoire en XNUMXK, ce qui est inaccessible lors de l'utilisation de systèmes de stockage RAID classiques.
Mais la principale caractéristique du NeoSapphire™ H710 est l'exécution de deux nœuds sous forme de boîtiers distincts, chacun possédant sa propre copie des données. La synchronisation des nœuds s'effectue via l'interface externe InfiniBand. Grâce à cette architecture, il est possible de distribuer des nœuds à différents emplacements jusqu'à une distance de 100 m, offrant ainsi une solution de reprise après sinistre Cross-Rack. Les deux nœuds fonctionnent de manière totalement synchrone. Du côté de l'hôte, le H710 ressemble à un système de stockage ordinaire à double contrôleur. Par conséquent, il n’est pas nécessaire d’effectuer des options logicielles ou matérielles supplémentaires ou des paramètres particulièrement complexes.
Si nous comparons toutes les solutions de reprise après sinistre Cross-Rack décrites ci-dessus, l'option d'AccelStor se démarque nettement des autres :
Architecture rien partagé AccelStor NeoSapphire™
Système de stockage « virtualiseur » logiciel ou matériel
Solution basée sur la réplication
Disponibilité
Panne de serveur
Aucun temps d'arrêt
Aucun temps d'arrêt
Aucun temps d'arrêt
Échec du commutateur
Aucun temps d'arrêt
Aucun temps d'arrêt
Aucun temps d'arrêt
Panne du système de stockage
Aucun temps d'arrêt
Aucun temps d'arrêt
Temps d'arrêt
Panne entière du cabinet
Aucun temps d'arrêt
Aucun temps d'arrêt
Temps d'arrêt
Coût et complexité
Coût de la solution
Faible*
Haut
Haut
Complexité du déploiement
faible
Haut
Haut
*AccelStor NeoSapphire™ est toujours une baie All Flash, qui par définition ne coûte pas « 3 kopecks », d'autant plus qu'elle dispose d'une double réserve de capacité. Cependant, lorsque l’on compare le coût final d’une solution basée sur celle-ci avec des solutions similaires proposées par d’autres fournisseurs, le coût peut être considéré comme faible.
La topologie de connexion des serveurs d'applications et des nœuds de baies All Flash ressemblera à ceci :
Lors de la planification de la topologie, il est également fortement recommandé de dupliquer les commutateurs de gestion et d'interconnecter les serveurs.
Ici et plus loin, nous parlerons de la connexion via Fibre Channel. Si vous utilisez iSCSI, tout sera pareil, ajusté en fonction des types de commutateurs utilisés et des paramètres de baie légèrement différents.
Travaux préparatoires sur le tableau
Matériel et logiciels utilisés
Spécifications du serveur et du commutateur
Composants
description
Serveurs Oracle Database 11g
Deux
Système d'exploitation du serveur
Oracle Linux
Version de la base de données Oracle
11g (RAC)
Processeurs par serveur
Deux processeurs Intel® Xeon® E16-5 v2667 à 2 cœurs à 3.30 GHz
Mémoire physique par serveur
128GB
Réseau FC
FC 16 Gb/s avec multiacheminement
FC-HBA
Émulex Lpe-16002B
Ports 1GbE publics dédiés à la gestion des clusters
Adaptateur Ethernet Intel RJ45
Commutateur FC 16 Go/s
Brocart 6505
Ports 10GbE privés dédiés pour la synchronisation des données
Intel X520
Spécifications de la baie XNUMX % Flash AccelStor NeoSapphire™
Composants
description
Système de stockage
Modèle haute disponibilité NeoSapphire™ : H710
Version illustrée
4.0.1
Nombre total de lecteurs
48
Taille du lecteur
1.92TB
Type de lecteur
SSD
Ports cibles FC
16 ports 16 Go (8 par nœud)
Ports de gestion
Le câble Ethernet 1GbE se connectant aux hôtes via un commutateur Ethernet
Port de battement de coeur
Le câble Ethernet 1GbE reliant deux nœuds de stockage
Port de synchronisation des données
Câble InfiniBand 56 Gb/s
Avant de pouvoir utiliser un tableau, vous devez l'initialiser. Par défaut, l'adresse de contrôle des deux nœuds est la même (192.168.1.1). Vous devez vous y connecter un par un, définir de nouvelles adresses de gestion (déjà différentes) et configurer la synchronisation de l'heure, après quoi les ports de gestion peuvent être connectés à un seul réseau. Ensuite, les nœuds sont combinés en une paire HA en attribuant des sous-réseaux pour les connexions Interlink.
Une fois l'initialisation terminée, vous pouvez gérer la baie à partir de n'importe quel nœud.
Ensuite, nous créons les volumes nécessaires et les publions sur les serveurs d'applications.
Il est fortement recommandé de créer plusieurs volumes pour Oracle ASM car cela augmentera le nombre de cibles pour les serveurs, ce qui améliorera à terme les performances globales (plus d'informations sur les files d'attente dans un autre ).
Configurer les tests
Nom du volume de stockage
Taille du volume
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Refaire01
100GB
Refaire02
100GB
Refaire03
100GB
Refaire04
100GB
Refaire05
100GB
Refaire06
100GB
Refaire07
100GB
Refaire08
100GB
Refaire09
100GB
Refaire10
100GB
Quelques explications sur les modes de fonctionnement du réseau et les processus se produisant dans les situations d'urgence
L'ensemble de données de chaque nœud possède un paramètre « numéro de version ». Après l'initialisation initiale, il est identique et égal à 1. Si pour une raison quelconque le numéro de version est différent, alors les données sont toujours synchronisées de l'ancienne version vers la plus jeune, après quoi le numéro de la version la plus jeune est aligné, c'est-à-dire cela signifie que les copies sont identiques. Raisons pour lesquelles les versions peuvent être différentes :
- Redémarrage programmé de l'un des nœuds
- Un accident sur l’un des nœuds dû à un arrêt brutal (alimentation électrique, surchauffe…).
- Connexion InfiniBand perdue avec impossibilité de synchronisation
- Un crash sur l'un des nœuds en raison d'une corruption de données. Ici, vous devrez créer un nouveau groupe HA et terminer la synchronisation de l'ensemble de données.
Dans tous les cas, le nœud qui reste en ligne augmente son numéro de version de un afin de synchroniser son jeu de données après restauration de la connexion avec la paire.
Si la connexion via la liaison Ethernet est perdue, Heartbeat passe temporairement à InfiniBand et revient dans les 10 secondes lorsqu'il est restauré.
Configuration des hôtes
Pour garantir la tolérance aux pannes et améliorer les performances, vous devez activer la prise en charge MPIO pour la baie. Pour ce faire, vous devez ajouter des lignes au fichier /etc/multipath.conf, puis redémarrer le service multipath.
Texte masquédispositifs {
dispositif {
fournisseur "AStor"
path_grouping_policy "group_by_prio"
path_selector "longueur de file d'attente 0"
path_checker "tour"
caractéristiques "0"
gestionnaire_matériel "0"
prio "const"
restauration immédiate
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names oui
détecter_prio oui
rr_min_io_rq 1
no_path_retry 0
}
}
Ensuite, pour qu'ASM fonctionne avec MPIO via ASMLib, vous devez modifier le fichier /etc/sysconfig/oracleasm, puis exécuter /etc/init.d/oracleasm scandisks
Texte masqué
# ORACLEASM_SCANORDER : Modèles de correspondance pour commander l'analyse du disque
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE : modèles de correspondance pour exclure les disques de l'analyse
ORACLEASM_SCANEXCLUDE="sd"
Noter
Si vous ne souhaitez pas utiliser ASMLib, vous pouvez utiliser les règles UDEV, qui constituent la base d'ASMLib.
À partir de la version 12.1.0.2 d'Oracle Database, l'option est disponible pour l'installation dans le cadre du logiciel ASMFD.
Il est impératif de s'assurer que les disques créés pour Oracle ASM sont alignés sur la taille de bloc avec laquelle la baie fonctionne physiquement (4K). Sinon, des problèmes de performances pourraient survenir. Il est donc nécessaire de créer des volumes avec les paramètres appropriés :
parted /dev/mapper/device-name mklabel gpt mkpart primaire 2048s 100% align-check optimal 1
Répartition des bases de données sur les volumes créés pour notre configuration de test
Nom du volume de stockage
Taille du volume
Mappage des LUN de volume
Détails du périphérique de volume ASM
La taille de l'unité d'allocation
Data01
200GB
Mappez tous les volumes de stockage sur tous les ports de données du système de stockage
Redondance : normale
Nom : DGDATA
Objectif :Fichiers de données
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redondance : normale
Nom : DGGRID1
Objectif : Grille : CRS et vote
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redondance : normale
Nom : DGGRID2
Objectif : Grille : CRS et vote
4MB
Grid05
1GB
Grid06
1GB
Refaire01
100GB
Redondance : normale
Nom : DGREDO1
Objectif : refaire le journal du thread 1
4MB
Refaire02
100GB
Refaire03
100GB
Refaire04
100GB
Refaire05
100GB
Refaire06
100GB
Redondance : normale
Nom : DGREDO2
Objectif : refaire le journal du thread 2
4MB
Refaire07
100GB
Refaire08
100GB
Refaire09
100GB
Refaire10
100GB
Paramètres de base de données
- Taille du bloc = 8K
- Espace d'échange = 16 Go
- Désactiver AMM (gestion automatique de la mémoire)
- Désactiver les grandes pages transparentes
Autres réglages
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ noyau.shmmax 103079215104
✓ noyau.shmall 31457280
✓ noyau.shmmn 4096
✓ noyau.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # ne définissez pas ceci si vous utilisez Linux x86
✓ vm.vfs_cache_pression=200
✓ vm.nr_hugepages = 57000 XNUMX
# vi /etc/security/limits.conf
✓ grille douce nproc 2047
✓ grille dure nproc 16384
✓ grille soft nofile 1024
✓ grille rigide nofile 65536
✓ grille soft stack 10240
✓ grille pile dure 32768
✓ Oracle Soft Nproc 2047
✓ oracle dur nproc 16384
✓ Oracle Soft Nofile 1024
✓ oracle dur nofile 65536
✓ pile logicielle Oracle 10240
✓ pile dure Oracle 32768
✓ memlock souple 120795954
✓ memlock dur 120795954
sqlplus "/as sysdba"
alter system set process=2000 scope=spfile;
modifier l'ensemble système open_cursors=2000 scope=spfile;
modifier l'ensemble système session_cached_cursors=300 scope=spfile ;
modifier l'ensemble système db_files=8192 scope=spfile ;
Test d'échec
À des fins de démonstration, HammerDB a été utilisé pour émuler une charge OLTP. Configuration de HammerDB :
Nombre d'entrepôts
256
Total des transactions par utilisateur
1000000000000
Utilisateurs virtuels
256
Le résultat a été un TPM de 2.1 millions, ce qui est loin de la limite de performances de la baie. , mais constitue un « plafond » pour la configuration matérielle actuelle des serveurs (principalement due aux processeurs) et leur nombre. Le but de ce test est toujours de démontrer la tolérance aux pannes de la solution dans son ensemble, et non d'atteindre des performances maximales. Nous nous baserons donc simplement sur ce chiffre.
Test de défaillance de l'un des nœuds
Les hôtes ont perdu une partie des chemins d'accès au stockage, continuant à parcourir les chemins restants avec le deuxième nœud. Les performances ont chuté pendant quelques secondes en raison de la reconstruction des chemins, puis sont revenues à la normale. Il n'y a eu aucune interruption de service.
Test de défaillance d'armoire avec tous les équipements
Dans ce cas, les performances ont également chuté pendant quelques secondes en raison de la restructuration des chemins, puis sont revenues à la moitié de leur valeur d'origine. Le résultat a été réduit de moitié par rapport au résultat initial en raison de l'exclusion d'un serveur d'applications du fonctionnement. Il n’y a pas non plus eu d’interruption de service.
S'il est nécessaire de mettre en œuvre une solution de reprise après sinistre multi-rack tolérante aux pannes pour Oracle à un coût raisonnable et avec peu d'efforts de déploiement/d'administration, alors Oracle RAC et l'architecture travaillent ensemble. sera l'une des meilleures options. Au lieu d'Oracle RAC, il peut y avoir n'importe quel autre logiciel permettant le clustering, les mêmes SGBD ou systèmes de virtualisation, par exemple. Le principe de construction de la solution restera le même. Et le résultat final est nul pour le RTO et le RPO.
Source: habr.com