Et des meilleures pratiques
Architecture
Suggérer des modifications
PDF
Les hôtes SAP HANA sont connectés aux contrôleurs de stockage via une infrastructure FCP redondante et un logiciel multivoie. Une infrastructure de commutateur FCP redondante est nécessaire pour assurer une connectivité hôte vers stockage SAP HANA tolérante aux pannes en cas de défaillance d'un commutateur ou d'un adaptateur de bus hôte (HBA). La segmentation appropriée doit être configurée au niveau du switch pour permettre à tous les hôtes HANA d'atteindre les LUN requises sur les contrôleurs de stockage.
Différents modèles de la gamme de produits FAS peuvent être utilisés au niveau de la couche de stockage. Le nombre maximal d'hôtes SAP HANA connectés au stockage est défini par les exigences de performances SAP HANA. Le nombre de tiroirs disques requis est déterminé par les exigences de capacité et de performance des systèmes SAP HANA.
La figure suivante présente un exemple de configuration avec huit hôtes SAP HANA reliés à une paire haute disponibilité de stockage.
Cette architecture peut évoluer en deux dimensions :
-
En ajoutant des hôtes SAP HANA et une capacité de disque au stockage, en supposant que les contrôleurs de stockage peuvent fournir des performances suffisantes sous la nouvelle charge afin de satisfaire les principaux indicateurs de performances (KPI)
-
En ajoutant davantage de systèmes de stockage et de capacité sur disque pour les hôtes SAP HANA supplémentaires
La figure suivante montre un exemple de configuration dans lequel davantage d'hôtes SAP HANA sont connectés aux contrôleurs de stockage. Dans cet exemple, il faut davantage de tiroirs disques pour répondre aux exigences de capacité et de performances des 3 16 hôtes SAP HANA. Selon les besoins en débit total, vous devez ajouter des connexions FC supplémentaires aux contrôleurs de stockage.
Quel que soit le modèle de stockage des systèmes FAS déployé, le paysage SAP HANA peut également être étendu par l'ajout de contrôleurs de stockage, comme l'illustre la figure suivante.
Sauvegarde SAP HANA
Le logiciel NetApp ONTAP offre un mécanisme intégré de sauvegarde des bases de données SAP HANA. La sauvegarde Snapshot basée sur le stockage est une solution de sauvegarde entièrement prise en charge et intégrée disponible pour les systèmes de conteneurs uniques SAP HANA et pour les systèmes SAP HANA MDC à un seul locataire.
Les sauvegardes Snapshot basées sur le stockage sont implémentées grâce au plug-in NetApp SnapCenter pour SAP HANA, qui permet d'effectuer des sauvegardes Snapshot cohérentes basées sur le stockage à l'aide des interfaces fournies par la base de données SAP HANA. SnapCenter enregistre les sauvegardes Snapshot dans le catalogue des sauvegardes SAP HANA, de sorte que les sauvegardes soient visibles dans le studio SAP HANA et peuvent être sélectionnées pour les opérations de restauration et de reprise.
Grâce au logiciel NetApp SnapVault, les copies Snapshot créées sur le stockage primaire peuvent être répliquées sur le stockage de sauvegarde secondaire contrôlé par SnapCenter. Différentes règles de conservation des sauvegardes peuvent être définies selon l'emplacement des sauvegardes : dans le stockage primaire ou dans le stockage secondaire. Le plug-in SnapCenter pour base de données SAP HANA gère la conservation des sauvegardes de données basées sur des copies Snapshot et des sauvegardes de journaux, notamment le nettoyage du catalogue de sauvegardes. Le plug-in SnapCenter pour base de données SAP HANA permet également d'exécuter un contrôle d'intégrité des blocs de la base de données SAP HANA en effectuant une sauvegarde basée sur des fichiers.
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 des avantages significatifs par rapport aux sauvegardes basées sur des fichiers. Ces avantages sont les suivants :
-
Sauvegarde plus rapide (quelques minutes)
-
Restauration plus rapide sur la couche de stockage (quelques minutes)
-
Aucun impact sur les performances de l'hôte, du réseau ou du stockage de la base de données SAP HANA pendant la sauvegarde
-
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 après incident de SAP HANA peut être exécutée sur la couche de base de données à l'aide de la réplication du système SAP ou sur la couche de stockage à l'aide de 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 la solution de reprise sur incident SAP HANA qui utilise SnapCenter, 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 après incident sur trois sites, qui utilise la réplication SnapMirror synchrone vers le data Center de reprise après incident local et SnapMirror asynchrone pour répliquer les données vers le data Center de reprise après incident distant.
La réplication des données à l'aide de SnapMirror synchrone assure un RPO nul. La distance entre le data Center principal et le centre de reprise après incident local 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 par la réplication des données vers un troisième data Center distant à 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 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 après incident peuvent être utilisés en tant que systèmes de développement et de test en temps normal. En cas d'incident, les systèmes de dév/test doivent être arrêtés et démarrés est en tant que serveurs de production de reprise sur incident.
Les deux méthodes de réplication permettent d'exécuter des tests du workflow de reprise d'activité sans affecter le RPO et RTO. Les volumes FlexClone sont créés sur le stockage et 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 reprises après le retour de la relation SnapMirror à l'état insync. En cas de panne du stockage primaire, les E/S des applications peuvent reprendre 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 NetApp 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 les charges 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.
