SAP HANA : une base de données in-memory
Thomas Leconte - Consultant MTI France
SQL Server, DB2 ou encore Oracle, pour ne citer que les plus connues : les bases de données associées aux applications SAP reflètent, pour chaque entreprise, un choix interne. En raison de compétences existantes, de gros volumes à traiter ou encore d'une infrastructure d'ores et déjà adaptée à tel ou tel SGBD. Mais en 2012, petite révolution : SAP dévoile un serveur d'application complet et prêt-à-l'emploi pour sa Business Suite (complète ou par module), embarquant une base de données in-memory.
Concrètement, cela signifie que les données sont stockées et utilisées en mémoire RAM. Excellente pour les performances et les temps de traitement, cette solution fait cependant peser un risque substantiel sur la production : en cas de crash serveur, toutes les données seraient perdues sans une persistance des données sur disque.
En termes d'infrastructure, une base de données in-memory implique donc des choix bien spécifiques : outre un serveur disposant d'une RAM conséquente (de 128 Go à 6 To), il est impératif de sécuriser les données par deux processus distincts d'écriture sur disque. D'une part, l'écriture en temps réel dans un journal de logs de toutes les transactions opérées et, d'autre part, un dump complet de la base de données toutes les 5 minutes (par défaut) sur une partition dédiée.
La délicate question de la scalabilité d'une infrastructure SAP HANA
Le principe d'une base de données, c'est qu'elle grandit au fil du temps. Sur le plan de l'infrastructure, ce principe implique de disposer d'une architecture qui s'ajuste en fonction des besoins, afin d'éviter les écueils d'un sur-dimensionnement de départ ou d'un sous-dimensionnement trop rapide. Or, cette scalabilité diffère sensiblement selon le module applicatif SAP concerné.
En effet, seul Business Information Warehouse est à ce jour construit sur un modèle de bases de données analytiques (OLAP). Contrairement à l'ensemble des autres modules (ERP, CRM, SRM...) qui disposent d'un modèle transactionnel (OLTP). En matière d'infrastructure, la distinction est primordiale puisque c'est d'elle dont va découler le format de scalabilité à retenir.
Ainsi, avec une base de données OLAP, il est possible de retenir un modèle scale-out. Concrètement, le modèle scale-out permet de concevoir une infrastructure où le cluster de serveurs peut s'étoffer par ajout successif de nœuds au gré de la croissance de la base de données. Si à terme SAP tend à permettre cette solution sur l'ensemble de ses modules, le principe du scale-up est pour l'instant la seule option pour la plupart d'entre eux, qui prévoit le « simple » ajout de RAM au serveur lorsque cela s'avère nécessaire.
Dans les 2 cas, l'association à une baie de stockage et à au moins un nœud passif permet de sécuriser la production par une reprise rapide de l'activité en cas de maintenance ou de panne d'un des nœuds actifs.
SAP HANA : appliances ou TDI ?
Au lancement de HANA, SAP, conscient de l'influence de l'infrastructure sur les performances d'une base de données, a privilégié la distribution sous la forme d'appliances. A savoir des machines (racks avec disques embarqués) ou armoires (pour le modèle scale-out) avec CPU, mémoire et stockage pré-installés en usine, et sur lesquelles sont déployées un OS (Suze ou RedHat généralement) et la base de données HANA.
Une solution qui permettait à l'éditeur, ainsi qu'à son client, de s'assurer du respect du design de l'infrastructure et du respect de la matrice de compatibilité lors des mises à jour, afin d'obtenir les meilleures performances possibles. Robuste et sécurisante, cette option est cependant relativement rigide tout en impliquant un coût assez élevé. En raison, principalement, de la multiplication des appliances pour chaque environnement : production, développement, tests, etc.
Pour éviter ces écueils, l'option de la TDI (Tailored Datacenter Integration) est également parfaitement envisageable. Dans ce cas, il est impératif de disposer de compétences (internes ou auprès d'un intégrateur) spécifiques à SAP HANA, afin de garantir les performances de chaque cluster. Plus souple, cette option est aussi, dans la très grande majorité des cas, plus économique. En effet, la formule TDI rend possible la mutualisation des infrastructures pour HANA et les serveurs d'application (AS) de chaque module SAP. À condition, bien sûr, de bien isoler les environnements.
En bref, si des éléments d'infrastructure entrant dans la matrice de compatibilité de SAP HANA sont pré-existants, les coûts opérationnels associés à l'intégration d'HANA permettront à l'option TDI de rester toujours plus compétitive. Dans le cas contraire, et à condition d'accepter une certaine rigidité corollaire à un strict respect du modèle d'infrastructure requis, la formule des appliances sera un choix judicieux.
Concrètement, cela signifie que les données sont stockées et utilisées en mémoire RAM. Excellente pour les performances et les temps de traitement, cette solution fait cependant peser un risque substantiel sur la production : en cas de crash serveur, toutes les données seraient perdues sans une persistance des données sur disque.
En termes d'infrastructure, une base de données in-memory implique donc des choix bien spécifiques : outre un serveur disposant d'une RAM conséquente (de 128 Go à 6 To), il est impératif de sécuriser les données par deux processus distincts d'écriture sur disque. D'une part, l'écriture en temps réel dans un journal de logs de toutes les transactions opérées et, d'autre part, un dump complet de la base de données toutes les 5 minutes (par défaut) sur une partition dédiée.
La délicate question de la scalabilité d'une infrastructure SAP HANA
Le principe d'une base de données, c'est qu'elle grandit au fil du temps. Sur le plan de l'infrastructure, ce principe implique de disposer d'une architecture qui s'ajuste en fonction des besoins, afin d'éviter les écueils d'un sur-dimensionnement de départ ou d'un sous-dimensionnement trop rapide. Or, cette scalabilité diffère sensiblement selon le module applicatif SAP concerné.
En effet, seul Business Information Warehouse est à ce jour construit sur un modèle de bases de données analytiques (OLAP). Contrairement à l'ensemble des autres modules (ERP, CRM, SRM...) qui disposent d'un modèle transactionnel (OLTP). En matière d'infrastructure, la distinction est primordiale puisque c'est d'elle dont va découler le format de scalabilité à retenir.
Ainsi, avec une base de données OLAP, il est possible de retenir un modèle scale-out. Concrètement, le modèle scale-out permet de concevoir une infrastructure où le cluster de serveurs peut s'étoffer par ajout successif de nœuds au gré de la croissance de la base de données. Si à terme SAP tend à permettre cette solution sur l'ensemble de ses modules, le principe du scale-up est pour l'instant la seule option pour la plupart d'entre eux, qui prévoit le « simple » ajout de RAM au serveur lorsque cela s'avère nécessaire.
Dans les 2 cas, l'association à une baie de stockage et à au moins un nœud passif permet de sécuriser la production par une reprise rapide de l'activité en cas de maintenance ou de panne d'un des nœuds actifs.
SAP HANA : appliances ou TDI ?
Au lancement de HANA, SAP, conscient de l'influence de l'infrastructure sur les performances d'une base de données, a privilégié la distribution sous la forme d'appliances. A savoir des machines (racks avec disques embarqués) ou armoires (pour le modèle scale-out) avec CPU, mémoire et stockage pré-installés en usine, et sur lesquelles sont déployées un OS (Suze ou RedHat généralement) et la base de données HANA.
Une solution qui permettait à l'éditeur, ainsi qu'à son client, de s'assurer du respect du design de l'infrastructure et du respect de la matrice de compatibilité lors des mises à jour, afin d'obtenir les meilleures performances possibles. Robuste et sécurisante, cette option est cependant relativement rigide tout en impliquant un coût assez élevé. En raison, principalement, de la multiplication des appliances pour chaque environnement : production, développement, tests, etc.
Pour éviter ces écueils, l'option de la TDI (Tailored Datacenter Integration) est également parfaitement envisageable. Dans ce cas, il est impératif de disposer de compétences (internes ou auprès d'un intégrateur) spécifiques à SAP HANA, afin de garantir les performances de chaque cluster. Plus souple, cette option est aussi, dans la très grande majorité des cas, plus économique. En effet, la formule TDI rend possible la mutualisation des infrastructures pour HANA et les serveurs d'application (AS) de chaque module SAP. À condition, bien sûr, de bien isoler les environnements.
En bref, si des éléments d'infrastructure entrant dans la matrice de compatibilité de SAP HANA sont pré-existants, les coûts opérationnels associés à l'intégration d'HANA permettront à l'option TDI de rester toujours plus compétitive. Dans le cas contraire, et à condition d'accepter une certaine rigidité corollaire à un strict respect du modèle d'infrastructure requis, la formule des appliances sera un choix judicieux.