Bonjour
Nous envisageons de changer d'infra et d'utiliser des partitions hostées pour faire de la réplication par Powerha
2 machines power 9
La prod avec 1 partition host de service qui gère le matériel et powerha et une partition hostées de production ( IASP )
le backup avec 1 partition hostée de réplication et une partition hostée de Dev
Est ce que vous utilisez ou avez utilisé les partitions hostées ?
Si oui est ce que vous avez constaté des impacts sur les performances (accès disques ) ?
Merci pour votre retour d'expérience négatif ou positif
partitions hostées (autrement appelé I dans I)
Re: partitions hostées (autrement appelé I dans I)
Bonjour,
Cette solution n'est pas vraiment du PowerHA, elle fonctionne mais elle ne sécurise pas l'environnement comme il devrait l'être.
Je m'explique.
PowerHA est une solution nécessitant que les données (programmes, fichiers, et les autres objets utilisés dans les applications) soient stockées dans un iASP. Et c'est cet iASP qui sera sous contrôle de la réplication.
Une telle partition dispose donc de deux ASP, le système (SYSBAS) et l'iASP pour les données.
Le second node du cluster, celui qui fait office de secours est actif, son ASP système est opérationnel et contient une version opérationnelle d'Operating System avec sa propre adresse TCP/IP. Les deux systèmes sont donc actifs en simultané.
Ainsi, en cas de bascule, il n'y a pas à démarrer le système de secours puisqu'il est déjà démarré. Il suffit juste de mettre la copie mirrorée de l'iASP en fonction (quelques secondes) pour disposer d'un système opérationnel prêt à l'exploitation.
Dans la solution que évoquez, les deux partitions (Prod et Secours) ne disposent pas d'un iASP, elles n'ont qu'un système classique.
Mais elles sont chacunes hébergées dans une autre partition host et ce sont ces partitions host qui disposent d'un ASP système et d'un iASP. La partition de Prod est hébergée dans l'iASP de la partition host (idem pour le backup) qui sera sous contrôle de PowerHA pour la réplication vers l'équivalent sur le Backup.
Cela signifie donc que l'intégralité de la partition de Prod est répliqué (pagination y compris) et que les adresses TCP/IP sont identiques entre la Prod et le Secours, pour cette raison, elles ne peuvent pas être démarrées simultanément.
Le secours est donc arrêté, en cas de bascule, ce secours peut dans certains, ne pas démarrer et il conviendra de faire un IPL D et dans le meilleur des cas, il démarrera en mode anormal car le système considérera qu'il a subit une panne.
Cette solution n'est clairement pas de la Haute Disponibilité comme le permet normalement PowerHA ou MIMIX ou autres solution de HA.
Dans cette architecture, ce sont les partitions host qui sont en PowerHA mais pas les partitions de Prod, cela permet en effet de répliquer les données mais c'est une solution peu recommandable. Elle fonctionne mais avec de nombreuses contraintes et complexifie l'infrastructure.
Si la partition host est arrêtée par erreur, une bascule PowerHA sera effectuée vers la partition host backup, mais il faudra ensuite redémarrer manuellement en mode anormal la partition de secours et là, les choses risquent de se gâter.
De plus, cette solution utilise la technologie de réplication Geographic Mirroring, il s'agit d'une technologie encore supportée mais désuète car elle utilise la CPU du POWER pour la réplication et non pas les fonctions des SAN.
Pour résumer, c'est un technologie qui existe, qui peut avoir un intérêt dans des cas particuliers, mais il ne s'agit pas de Haute Disponibilité car son fonctionnement a été "contourné".
Une solution de réplication PowerHA en Haute Disponibilité nécessite que les partitions sécurisées migrent leurs données dans un iASP.
Solution supportée par IBM mais fortement déconseillée pour son niveau de disponibilité qui n'est pas assuré, pour les faibles performances et pour la complexité de l'infrastructure.
Cette solution n'est pas vraiment du PowerHA, elle fonctionne mais elle ne sécurise pas l'environnement comme il devrait l'être.
Je m'explique.
PowerHA est une solution nécessitant que les données (programmes, fichiers, et les autres objets utilisés dans les applications) soient stockées dans un iASP. Et c'est cet iASP qui sera sous contrôle de la réplication.
Une telle partition dispose donc de deux ASP, le système (SYSBAS) et l'iASP pour les données.
Le second node du cluster, celui qui fait office de secours est actif, son ASP système est opérationnel et contient une version opérationnelle d'Operating System avec sa propre adresse TCP/IP. Les deux systèmes sont donc actifs en simultané.
Ainsi, en cas de bascule, il n'y a pas à démarrer le système de secours puisqu'il est déjà démarré. Il suffit juste de mettre la copie mirrorée de l'iASP en fonction (quelques secondes) pour disposer d'un système opérationnel prêt à l'exploitation.
Dans la solution que évoquez, les deux partitions (Prod et Secours) ne disposent pas d'un iASP, elles n'ont qu'un système classique.
Mais elles sont chacunes hébergées dans une autre partition host et ce sont ces partitions host qui disposent d'un ASP système et d'un iASP. La partition de Prod est hébergée dans l'iASP de la partition host (idem pour le backup) qui sera sous contrôle de PowerHA pour la réplication vers l'équivalent sur le Backup.
Cela signifie donc que l'intégralité de la partition de Prod est répliqué (pagination y compris) et que les adresses TCP/IP sont identiques entre la Prod et le Secours, pour cette raison, elles ne peuvent pas être démarrées simultanément.
Le secours est donc arrêté, en cas de bascule, ce secours peut dans certains, ne pas démarrer et il conviendra de faire un IPL D et dans le meilleur des cas, il démarrera en mode anormal car le système considérera qu'il a subit une panne.
Cette solution n'est clairement pas de la Haute Disponibilité comme le permet normalement PowerHA ou MIMIX ou autres solution de HA.
Dans cette architecture, ce sont les partitions host qui sont en PowerHA mais pas les partitions de Prod, cela permet en effet de répliquer les données mais c'est une solution peu recommandable. Elle fonctionne mais avec de nombreuses contraintes et complexifie l'infrastructure.
Si la partition host est arrêtée par erreur, une bascule PowerHA sera effectuée vers la partition host backup, mais il faudra ensuite redémarrer manuellement en mode anormal la partition de secours et là, les choses risquent de se gâter.
De plus, cette solution utilise la technologie de réplication Geographic Mirroring, il s'agit d'une technologie encore supportée mais désuète car elle utilise la CPU du POWER pour la réplication et non pas les fonctions des SAN.
Pour résumer, c'est un technologie qui existe, qui peut avoir un intérêt dans des cas particuliers, mais il ne s'agit pas de Haute Disponibilité car son fonctionnement a été "contourné".
Une solution de réplication PowerHA en Haute Disponibilité nécessite que les partitions sécurisées migrent leurs données dans un iASP.
Solution supportée par IBM mais fortement déconseillée pour son niveau de disponibilité qui n'est pas assuré, pour les faibles performances et pour la complexité de l'infrastructure.