Scénario de gestion
En tant qu'administrateur de base de données SAP HANA, vous devez installer et administrer les systèmes SAP HANA à haute disponibilité. Vous devez comprendre le concept de base de la technologie de scale-out SAP HANA.
Mise à l'échelle de SAP HANA
Mise à l'échelle des données
Une technique que vous pouvez utiliser pour gérer la croissance des données planifiées est d'acheter plus de RAM physique que nécessaire initialement, de définir la limite d'affectation en fonction de vos besoins, puis de l'augmenter au fil du temps pour l'adapter à vos données. Une fois que vous avez atteint les limites physiques d'un seul serveur, vous pouvez effectuer une mise à l'échelle sur plusieurs ordinateurs pour créer un système SAP HANA distribué. Pour ce faire, vous pouvez répartir différents schémas et tables sur différents serveurs (séparation complète des données et des utilisateurs). Cependant, cela n'est pas toujours possible, par exemple, lorsqu'une seule table de faits est plus grande que la taille RAM du serveur.
La stratégie la plus importante pour mettre vos données à l'échelle est le partitionnement des données. Le partitionnement prend en charge la création de très grandes tables (milliards de lignes) en les divisant en morceaux plus petits qui peuvent être placés sur différentes machines. Le partitionnement est transparent pour la plupart des requêtes SQL et autres manipulations de données.
Performances de mise à l'échelle
La performance de SAP HANA est dérivée de son approche efficace et parallèle. Plus votre serveur SAP HANA possède de cœurs de calcul, meilleures sont les performances globales du système.
La mise à l'échelle des performances nécessite une compréhension plus détaillée de votre charge de travail et de vos attentes en matière de performances. À l'aide de simulations et d'estimations de vos charges de travail de requêtes typiques, vous pouvez déterminer la charge attendue qu'une installation SAP HANA typique peut facilement gérer. Au niveau de la charge de travail, une prévision approximative de l'évolutivité peut être établie en mesurant l'utilisation moyenne du processeur pendant l'exécution de la charge de travail. Par exemple, une utilisation moyenne du processeur de 45 % peut indiquer que le système peut être chargé 2X avant de montrer une réduction significative du temps de réponse de la requête individuelle.
Mise à l'échelle de l'application
Le partitionnement peut être utilisé pour mettre à l'échelle l'application car il prend en charge un nombre croissant de sessions simultanées et de requêtes analytiques complexes en répartissant les calculs sur plusieurs hôtes. Une attention particulière doit être apportée à la distribution des données afin que la majorité des requêtes correspondent aux règles d'élagage de partitionnement. Cela permet d'atteindre deux objectifs : diriger des utilisateurs différents vers des hôtes différents (équilibrage de charge) et éviter la surcharge réseau liée aux jointures de données fréquentes entre hôtes.
Mise à l'échelle du matériel
SAP HANA est proposé de plusieurs façons : sous la forme d'une appliance sur site, fournie dans un certain nombre de configurations et de « tailles » différentes par des partenaires matériels certifiés ou en utilisant le modèle d'intégration de centre de données sur mesure, et dans le cadre d'un service basé sur le Cloud. Cela crée différentes options de conception du système en ce qui concerne les variations de scale-up et de scale-out. Pour optimiser les performances et le débit, SAP vous recommande d'augmenter autant que possible (acquérir la configuration avec les spécifications de processeur et de mémoire les plus élevées pour la charge de travail de l'application), avant la mise à l'échelle (pour les déploiements avec des besoins en volume de données encore plus importants).
Remarque
Présentation de la haute disponibilité dans un système SAP HANA
Dans la figure Évolutivité/Évolutivité horizontale, la taille des systèmes SAP HANA passe de 1 To à 12 To. Dans les deux scénarios, scale-up et scale-out, aucune haute disponibilité n'est introduite. La haute disponibilité ne peut être introduite que dans une configuration de scale-out avec inclusion de nœuds de secours. Une configuration de scale-out avec une haute disponibilité est illustrée dans la figure Haute disponibilité et scale-out. Un ou plusieurs nœuds SAP HANA peuvent être configurés comme nœuds de secours. Un nœud de secours reprend automatiquement les opérations d'un hôte ayant échoué à l'aide de la fonctionnalité de basculement automatique de l'hôte de SAP HANA.
Dès que vous introduisez des nœuds de secours dans une configuration de scale-out SAP HANA, vous réservez des ressources pour l'événement d'une défaillance. Ces ressources ne peuvent pas être utilisées dans le système actif. Dans la figure Haute disponibilité et scale-out, un hôte est défini comme le nœud de secours. Cela signifie que notre système n'a plus que 11 nœuds actifs et que la taille totale de la base de données est réduite de 12 To à 11 To.
Une configuration évolutive, par défaut, n'a pas de capacités de haute disponibilité. Cela est dû au fait qu'un système de scale-up est constitué d'un serveur. Un système évolutif peut être rendu haute disponibilité en ajoutant un hôte de secours supplémentaire au système SAP HANA ou en configurant une configuration à l'aide de la réplication de stockage ou de la réplication du système.
Systèmes multi-hôtes (distribués)
Un système SAP HANA peut comprendre plusieurs bases de données isolées et peut être constitué d'un cluster de plusieurs hôtes. Il s'agit d'un système distribué à plusieurs hôtes ou d'un système de scale-out, et prend en charge l'évolutivité et la disponibilité.
Un système SAP HANA est identifié par un ID système unique (SID) et contient une ou plusieurs bases de données mutualisées et une base de données système. Les bases de données sont identifiées par un SID et un nom de base de données. Du point de vue de l'administration, il existe une distinction entre les tâches exécutées au niveau du système et celles exécutées au niveau de la base de données. Les clients de base de données, tels que le cockpit SAP HANA, se connectent à des bases de données spécifiques.
Un hôte est un ordinateur qui exécute des parties du système SAP HANA. La machine est composée d'une unité centrale, d'une mémoire, d'un stockage, d'un réseau et d'un système d'exploitation.
Une instance SAP HANA est l'ensemble des composants d'un système distribué qui sont installés sur un hôte. La figure Système à haute échelle disponible montre un système distribué qui s'exécute sur quatre hôtes. Dans cet exemple, chaque instance possède un serveur d'index et un serveur de noms.
Un ou plusieurs hôtes peuvent être configurés pour fonctionner en mode veille, de sorte que si un hôte actif échoue, un hôte de secours prend automatiquement sa place. Les serveurs d'index sur les hôtes de secours ne contiennent aucune donnée et ne reçoivent aucune requête.
Le serveur d'index contient tous les composants de base de données et de traitement. Chaque serveur d'index est un processus de système d'exploitation distinct et il a également ses propres volumes de disque. Lors du traitement des opérations de base de données, les serveurs d'index peuvent avoir besoin de transférer l'exécution de certaines opérations à d'autres serveurs qui possèdent les données impliquées dans l'opération.
Dans chaque système SAP HANA, il existe un serveur d'index primaire. Il stocke les métadonnées et contient le gestionnaire de transactions qui coordonne les transactions réparties impliquant plusieurs serveurs d'index.
Les clients de base de données peuvent envoyer leurs requêtes à n'importe quel serveur d'index. Si le serveur d'index contacté ne possède pas toutes les données impliquées, il délègue l'exécution de certaines opérations à d'autres serveurs d'index, collecte le résultat et le renvoie au client de base de données.
Dans un système réparti, il faut un composant central qui connaisse la topologie et le mode de répartition des données. Ce composant est le serveur de noms. Le serveur de noms sait quelles tables, répliques de tables ou partitions de tables se trouvent sur quel serveur d'index.
Lors du traitement d'une requête, les serveurs d'index interrogent le serveur de noms sur les emplacements des données concernées. Pour éviter un impact négatif sur les performances, les informations de topologie et de distribution sont répliquées et mises en cache sur chaque hôte. Dans chaque système SAP HANA, il existe un serveur de noms principal qui possède les données de topologie et de distribution. Ces données sont répliquées sur tous les autres serveurs de noms, appelés serveurs de noms secondaires. Les serveurs de noms secondaires écrivent les données répliquées dans un cache de la mémoire partagée à partir duquel les serveurs d'index de la même instance peuvent les lire.
Le serveur de noms principal possède sa propre persistance où il stocke les données du serveur de noms (données de topologie et de distribution). Les serveurs de noms secondaires n'ont pas de persistance car ils ne contiennent que des données répliquées.