Et des meilleures pratiques
Architecture
Suggérer des modifications
PDF
Des hôtes SAP HANA sont connectés aux contrôleurs de stockage via une infrastructure réseau redondante 10GbE ou plus rapide. La communication des données entre les hôtes SAP HANA et les contrôleurs de stockage repose sur le protocole NFS.
Une infrastructure de commutation redondante est recommandée pour assurer une connectivité hôte vers stockage SAP HANA tolérante aux pannes en cas de défaillance d'un commutateur ou d'une carte réseau. Les commutateurs peuvent agréger des performances de ports individuels avec des canaux de port pour s'afficher en tant qu'entité logique unique au niveau de l'hôte.
Différents modèles de la gamme de produits des systèmes FAS peuvent être combinés au niveau de la couche de stockage afin de permettre la croissance et les besoins de performances et de capacité variables. Le nombre maximal d'hôtes SAP HANA pouvant être connectés au système de stockage est défini par les exigences de performances SAP HANA et le modèle du contrôleur NetApp utilisé. Le nombre de tiroirs disques requis n'est déterminé que par les exigences de capacité et de performance des systèmes SAP HANA. La figure suivante montre un exemple de configuration avec huit hôtes SAP HANA reliés à une paire haute disponibilité du stockage.
La figure suivante présente un exemple d'utilisation de VMware vSphere comme couche de virtualisation.
L'architecture peut évoluer en deux dimensions :
-
En ajoutant des hôtes SAP HANA et/ou une capacité de stockage supplémentaire au stockage existant, si les contrôleurs de stockage offrent des performances suffisantes pour satisfaire les indicateurs clés de performances (KPI, Key Performance Indicators) SAP actuels.
-
En ajoutant davantage de systèmes de stockage avec une capacité de stockage supplémentaire pour les hôtes SAP HANA supplémentaires
La figure suivante présente un exemple de configuration dans laquelle davantage d'hôtes SAP HANA sont connectés aux contrôleurs de stockage. Dans cet exemple, il faut davantage de tiroirs disques pour satisfaire à la fois les besoins en capacité et en performances de 16 hôtes SAP HANA. Selon les besoins de débit total, d'autres connexions 10GbE (ou plus rapides) aux contrôleurs de stockage doivent être ajoutées.
Quel que soit le système FAS déployé, le paysage SAP HANA peut également être étendu en ajoutant des contrôleurs de stockage certifiés afin de répondre à la densité de nœud souhaitée (figure suivante).
Sauvegarde SAP HANA
Le logiciel ONTAP présent sur tous les contrôleurs de stockage NetApp offre un mécanisme intégré pour sauvegarder les bases de données SAP HANA sans nuire aux performances. Les sauvegardes Snapshot NetApp basées sur le stockage sont une solution de sauvegarde entièrement prise en charge et intégrée disponible pour les conteneurs uniques SAP HANA et pour les systèmes MDC (conteneur de base de données mutualisée SAP HANA) avec un ou plusieurs locataires.
Les sauvegardes Snapshot basées sur le stockage sont implémentées grâce au plug-in NetApp SnapCenter pour SAP HANA. Il est ainsi possible de créer des sauvegardes Snapshot cohérentes basées sur le stockage à l'aide des interfaces fournies de manière native par les bases de données SAP HANA. SnapCenter enregistre chacune des sauvegardes Snapshot dans le catalogue des sauvegardes SAP HANA. Par conséquent, les sauvegardes prises par SnapCenter sont visibles dans SAP HANA Studio et Cockpit où elles peuvent être sélectionnées directement pour les opérations de restauration et de reprise.
La technologie NetApp SnapMirror permet de répliquer les copies Snapshot créées sur un système de stockage sur un système de stockage secondaire contrôlé par SnapCenter. Différentes règles de conservation des sauvegardes peuvent ensuite être définies pour chaque jeu de sauvegarde sur le stockage primaire et pour les jeux de sauvegarde sur les systèmes de stockage secondaires. Le plug-in SnapCenter pour SAP HANA gère automatiquement la conservation des sauvegardes de données basées sur des copies Snapshot et des sauvegardes de journaux, y compris les opérations de gestion du catalogue de sauvegardes. Le plug-in SnapCenter pour SAP HANA permet également d'exécuter un contrôle d'intégrité des blocs de la base de données SAP HANA en exécutant une sauvegarde basée sur fichier.
Les journaux de la base de données peuvent être sauvegardés directement sur le stockage secondaire à l'aide d'un montage NFS, comme illustré dans la figure suivante.
Les sauvegardes Snapshot basées sur le stockage offrent un avantage considérable par rapport aux sauvegardes classiques basées sur des fichiers. Ces avantages sont, entre autres, les suivants :
-
Sauvegarde plus rapide (quelques minutes)
-
L'objectif de durée de restauration (RTO) est réduit grâce à une durée de restauration bien plus rapide sur la couche de stockage (quelques minutes), ainsi qu'à des sauvegardes plus fréquentes
-
Aucune dégradation des performances de l'hôte, du réseau ou du stockage de la base de données SAP HANA pendant les opérations de sauvegarde et de restauration
-
Réplication compacte et économique en bande passante sur le stockage secondaire en fonction des modifications apportées aux blocs
Pour plus d'informations sur la solution de sauvegarde et de restauration SAP HANA qui utilise SnapCenter, consultez "Tr-4614 : sauvegarde et restauration SAP HANA avec SnapCenter".
Reprise d'activité SAP HANA
La reprise d'activité de SAP HANA peut être effectuée soit sur la couche de base de données à l'aide de la réplication du système SAP HANA, soit sur la couche de stockage grâce aux technologies de réplication du stockage. La section suivante présente les solutions de reprise sur incident basées sur la réplication du stockage.
Pour plus d'informations sur les solutions de reprise sur incident SAP HANA, consultez "Tr-4646 : reprise après incident de SAP HANA avec réplication du stockage".
Réplication du stockage basée sur SnapMirror
La figure suivante présente une solution de reprise sur incident sur trois sites qui utilise la réplication SnapMirror synchrone vers le data Center local de reprise après incident et SnapMirror asynchrone pour répliquer les données vers le data Center distant de reprise après incident.
La réplication des données à l'aide de SnapMirror synchrone assure un RPO nul. La distance entre le data Center principal et le data Center local de reprise après incident est limitée à environ 100 km.
La protection contre les défaillances du site principal et du site de reprise sur incident local est effectuée en répliquant les données vers un troisième data Center de reprise après incident à distance à l'aide de SnapMirror asynchrone. Le RPO dépend de la fréquence des mises à jour de réplication et de la rapidité de leur transfert. En théorie, la distance est illimitée, mais la limite dépend de la quantité de données à transférer et de la connexion disponible entre les centres de données. Les valeurs RPO typiques sont comprises dans une plage de 30 minutes à plusieurs heures.
Le RTO des deux méthodes de réplication dépend principalement du temps nécessaire pour démarrer la base de données HANA sur le site de reprise d'activité et charger les données dans la mémoire. L'hypothèse que le débit de lecture des données est de 1 000 Mbit/s, le chargement de 1 To de données prendra environ 18 minutes.
Les serveurs des sites de reprise d'activité peuvent être utilisés en tant que systèmes de développement/test pendant le fonctionnement normal. Dans le cas d'un incident, les systèmes de dév/test devront être arrêtés et démarrés est comme des serveurs de production de reprise sur incident.
Les deux méthodes de réplication permettent d'exécuter des tests du flux de travail de reprise d'activité sans affecter le RPO et RTO. Les volumes FlexClone sont créés sur le système de stockage et sont rattachés aux serveurs de test de reprise après incident.
La réplication synchrone offre le mode StrictSync. Si l'écriture sur le stockage secondaire n'est pas terminée, pour une raison quelconque, les E/S de l'application échouent, ce qui permet de s'assurer que les systèmes de stockage primaire et secondaire sont identiques. Les E/S de l'application vers le système primaire sont CV uniquement après le retour de la relation SnapMirror à l'état insync. En cas de défaillance du stockage primaire, les E/S des applications peuvent être reprises sur le stockage secondaire après le basculement, sans perte de données. En mode StrictSync, le RPO est toujours zéro.
Réplication du stockage basée sur MetroCluster
La figure suivante présente une vue d'ensemble générale de la solution. Le cluster de stockage de chaque site assure une haute disponibilité locale et est utilisé pour la charge de travail de production. Les données de chaque site sont répliquées de manière synchrone sur l'autre emplacement et sont disponibles en cas de basculement.
