Créez une solution de basculement basée sur Oracle RAC et l'architecture AccelStor Shared-Nothing

Un nombre considérable d'applications d'entreprise et de systèmes de virtualisation ont leurs propres mécanismes pour créer des solutions tolérantes aux pannes. En particulier, 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 du serveur / de l'application. Pour travailler dans ce mode, un stockage commun est requis, dont le rôle est généralement le stockage.

Comme nous l'avons déjà expliqué dans l'un de nos articles , le système de stockage en lui-même, malgré la présence de composants dupliqués (y compris les contrôleurs), présente encore des points de défaillance - principalement sous la forme d'un ensemble de données unique. Par conséquent, pour construire une solution Oracle avec des exigences de fiabilité accrues, le schéma «N serveurs - un stockage» doit être compliqué.

Tout d'abord, bien sûr, vous devez décider des risques contre lesquels nous essayons de nous assurer. Dans cet article, nous ne considérerons pas la protection contre les menaces telles qu'une météorite est arrivée. La création d'une solution de reprise après sinistre dispersée géographiquement restera donc un sujet pour l'un des articles suivants. Nous examinons ici la solution de récupération après sinistre Cross-Rack, lorsque la protection est construite au niveau des armoires de serveur. 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 tous les équipements et logiciels nécessaires pour assurer le fonctionnement des bases de données Oracle quel que soit l'état du "voisin". En d'autres termes, en utilisant la solution de reprise après sinistre Cross-Rack, nous éliminons les risques d'échec:

• Serveurs d'applications Oracle
• Systèmes de stockage
• Systèmes de commutation
• Panne complète de tous les équipements de l'armoire:
  
  • Panne de courant
  • Panne du système de refroidissement
  • Facteurs externes (homme, nature, etc.)

La duplication des serveurs Oracle implique le principe même d'Oracle RAC et est implémentée via l'application. La duplication des outils de commutation n'est pas non plus un problème. Mais avec la duplication du système de stockage, tout n'est pas si simple.

L'option la plus simple consiste à répliquer les données du stockage principal vers la sauvegarde. Synchrone ou asynchrone, selon les capacités de stockage. La réplication asynchrone soulève immédiatement la question de la cohérence des données avec Oracle. Mais même s'il existe une intégration logicielle avec l'application, en tout cas, en cas d'accident sur le système de stockage principal, une intervention manuelle des administrateurs sera nécessaire afin de basculer le cluster vers le stockage de sauvegarde.

Une option plus complexe est celle des «virtualiseurs» logiciels et / ou matériels des systèmes de stockage, qui élimineront les problèmes de cohérence et d'intervention manuelle. 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 effrayent beaucoup.

Pour les scénarios tels que la reprise après sinistre sur plusieurs racks, la baie All Flash AccelStor NeoSapphire ™ H710 utilisant l'architecture Shared-Nothing est parfaite . Ce modèle est un système de stockage à deux unités utilisant sa propre technologie FlexiRemap® pour travailler avec des lecteurs flash. Grâce au FlexiRemap® NeoSapphire ™ H710, il peut fournir jusqu'à 600K IOPS @ 4K en écriture aléatoire et 1M + IOPS @ 4K en lecture aléatoire, ce qui est impossible avec un stockage RAID classique.

Mais la principale caractéristique du NeoSapphire ™ H710 est l'exécution de deux nœuds en tant que boîtiers séparés, chacun ayant sa propre copie des données. La synchronisation des nœuds s'effectue via l'interface externe InfiniBand. Grâce à cette architecture, les nœuds peuvent être répartis sur différents emplacements sur des distances allant jusqu'à 100 m, fournissant ainsi la solution de reprise après sinistre Cross-Rack. Les deux nœuds fonctionnent complètement en mode synchrone. Du côté de l'hôte, le H710 ressemble à un stockage ordinaire à double contrôleur. Par conséquent, aucune option logicielle et matérielle supplémentaire et des paramètres particulièrement complexes ne doivent être effectués.

Si vous comparez toutes les solutions de reprise après incident Cross-Rack décrites ci-dessus, la version AccelStor se démarque des autres:

* 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 réserve de capacité double. Cependant, en comparant le coût total de la solution basée sur celle-ci avec des coûts similaires d'autres fournisseurs, le coût peut être considéré comme faible.

La topologie de connexion des serveurs d'applications et de tous les nœuds de baies Flash ressemblera à ceci:

Lors de la planification de la topologie, il est également fortement recommandé de dupliquer les commutateurs de gestion et les interconnexions de serveurs.

Ci-après, nous parlerons de la connexion via Fibre Channel. Dans le cas de l'utilisation d'iSCSI, tout sera le même, ajusté pour les types de commutateurs utilisés et les paramètres de baie légèrement différents.

Travaux préparatoires sur le réseau

Avant de commencer à 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 et 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. Après cela, les nœuds sont combinés en une paire HA en attribuant des sous-réseaux aux connexions Interlink.

Une fois l'initialisation terminée, vous pouvez contrôler la baie à partir de n'importe quel nœud.

Ensuite, créez les volumes nécessaires et publiez-les pour 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 finalement les performances globales (plus d'informations sur les files d'attente dans un autre article ).

Quelques explications sur les modes de fonctionnement de la baie et les processus qui se produisent dans les situations d'urgence

Chaque jeu de données de noeud a 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, il y a toujours une synchronisation des données de l'ancienne version vers la plus jeune, après quoi le numéro est aligné pour la version la plus jeune, c'est-à-dire cela signifie que les copies sont identiques. Raisons pour lesquelles les versions peuvent varier:

• Redémarrage planifié de l'un des nœuds
• Un accident sur l'un des nœuds dû à un arrêt brutal (alimentation, surchauffe, etc.).
• Connexion InfiniBand rompue avec incapacité de synchronisation
• Plantage sur l'un des nœuds en raison d'une corruption des données. Cela nécessitera déjà la création d'un nouveau groupe HA et une synchronisation complète de l'ensemble de données.

Dans tous les cas, le nœud restant en ligne augmente son numéro de version de un, de sorte qu'après avoir reconnecté la paire, synchronisez son ensemble de données.

Si la connexion est perdue via la liaison Ethernet, Heartbeat bascule temporairement vers InfiniBand et revient dans les 10 secondes après sa restauration.

Configuration d'hôte

Pour garantir la tolérance aux pannes et augmenter les performances, vous devez activer la prise en charge MPIO pour la baie. Pour ce faire, ajoutez des lignes au fichier /etc/multipath.conf, puis rechargez le service multichemin

De plus, pour qu'ASM fonctionne avec MPIO via ASMLib, vous devez modifier le fichier / etc / sysconfig / oracleasm, puis exécuter /etc/init.d/oracleasm scandisks

Assurez-vous que les disques créés pour Oracle ASM sont alignés avec la taille du bloc avec lequel la baie travaille physiquement (4K). Sinon, des problèmes de performances peuvent survenir. Par conséquent, vous devez créer des volumes avec les paramètres appropriés:

parted / dev / mapper / device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1

Distribution de bases de données sur les volumes créés pour notre configuration de test

Test de tolérance aux pannes

À des fins de démonstration, HammerDB a été utilisé pour émuler la charge OLTP. Configuration de HammerDB:

En conséquence, l'indicateur TPM 2.1M a été obtenu, ce qui est loin de la limite de performance de la baie H710 , mais c'est le «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. Par conséquent, nous allons simplement construire sur cette figure.

Test de défaillance d'un des nœuds

Les hôtes ont perdu certains des chemins d'accès au magasin, continuant à travailler sur les autres avec le deuxième nœud. Les performances ont chuté pendant quelques secondes en raison de la restructuration des chemins, puis sont revenues à la normale. Aucune interruption de service n'est survenue.

Test de défaillance de l'armoire avec tous les équipements

Dans ce cas, la performance a également chuté pendant quelques secondes en raison de la restructuration des chemins, puis est revenue à la moitié de la valeur de l'indicateur d'origine. Le résultat a été divisé par deux par rapport à l'original en raison de l'exclusion du fonctionnement d'un serveur d'applications. Il n'y a pas eu non plus d'interruption de service.

Si vous avez besoin d'implémenter une solution de reprise après sinistre Cross-Rack tolérante aux pannes pour Oracle à un coût raisonnable et avec peu d'efforts de déploiement / administration, alors travailler avec Oracle RAC et l' architecture AccelStor Shared-Nothing serait l'une des meilleures options. Au lieu d'Oracle RAC, il peut y avoir tout autre logiciel qui prévoit la mise en cluster, le même SGBD ou les systèmes de virtualisation, par exemple. Le principe de construction de la solution restera le même. Et le score final est nul pour RTO et RPO.