Overlay IP est un cas particulier de mise en réseau dans AWS, qui est d’une importance cruciale dans les environnements SAP qui nécessitent une configuration à haute disponibilité. Dans cet article, nous comprendrons pourquoi Overlay IP est nécessaire, des détails techniques sur son fonctionnement et des modèles de conception dans SAP qui l’utilisent.
Qu’est-ce que l’IP de superposition
Dans la mise en réseau AWS, l’adresse IP privée au sein d’un VPC se lie à une interface réseau d’une instance EC2 pour fournir une connectivité réseau. Comme la liaison se produit de manière statique et que l’instance se trouve dans une zone, cela crée un défi pour les scénarios de haute disponibilité qui sont configurés dans les zones. Dans de tels scénarios, les applications clientes s’attendent à une seule adresse IP pour la connectivité des applications ; cependant, la même chose ne peut pas être obtenue avec une adresse IP statique.
L’IP superposée, aussi parfois appelée IP flottante, est un concept qui surmonte cette limitation. Notez que la terminologie IP flottante est également utilisée par Cette adresse IP, qui se trouve en dehors du bloc CIDR utilisé par le VPC auquel appartient l’instance EC2. Par exemple, si VPC utilise un bloc CIDR de 10.2.0.0/16, l’adresse IP de superposition est toute adresse IP en dehors de la plage 10.2.0.0 à 10.2.255.255. Il peut, par exemple, s’agir de 10.1.0.1 tout en garantissant qu’aucun autre VPC ou réseau appairé sur site ne l’utilise non plus.
Comment ça marche?
La première chose à comprendre est que Overlay IP en soi n’est pas une ressource AWS. Il s’agit de n’importe quelle adresse IP choisie sur le réseau. La seule exigence est que cette adresse soit routable. Donc, le principal aspect à comprendre ici est de savoir comment rendre l’adresse routable. La réponse simple à cette question est une table de routage dans AWS. Une table de routage selon la définition d’AWS est un simple ensemble de règles qui détermine où le trafic réseau provenant du sous-réseau ou de la passerelle d’un client est dirigé. Chaque itinéraire a une destination et une cible, ce qui peut prêter à confusion car les deux ont généralement la même signification. Or, dans le cas d’une table de routage, une destination est une plage d’adresses IP »où » nous voudrions que le trafic soit acheminé, et une cible est une passerelle, un trafic réseau ou une interface « à travers » par lequel le trafic est acheminé. Dans le cas d’une adresse IP de superposition, cette route est modifiée en spécifiant la destination comme adresse IP de superposition et la cible comme l’interface réseau élastique de l’instance pour laquelle nous souhaitons utiliser la superposition Adresse IP Cela peut être compris avec le schéma ci-dessous.
- L’application utilisateur/client fait une demande en utilisant l’adresse IP de superposition
- Ceci est d’abord reçu par la table de routage VPC/sous-réseau pour déterminer le prochain plan d’action
- La table de routage indique que l’adresse IP de superposition correspondante a la cible définie sur l’interface réseau élastique de l’instance
- Le trafic est acheminé vers l’interface réseau Elastic de l’instance, qui vérifie ensuite la destination en tant qu’IP de superposition
- L’IP de superposition, à ce stade, agit essentiellement comme l’adresse IP locale pour cette instance, puis traite la tâche
- En cas de basculement de cluster, la table de routage est mise à jour, généralement par un logiciel de cluster qui modifie la cible vers l’interface réseau élastique de l’autre instance
Cela signifie essentiellement que l’IP de superposition elle-même peut « flotter » entre les deux instances en fonction de l’instance actuellement active du point de vue du cluster. Par conséquent, du point de vue de l’utilisateur final/de l’application, cela garantit un basculement transparent sans aucun changement pour eux.
Un aspect important de cette configuration est la vérification source/destination de la propriété de l’instance EC2. Par défaut, les instances AWS EC2 sont censées être une source ou une destination de tout trafic qu’elles envoient ou reçoivent. Il s’agit d’un paramètre de sécurité (AWS concernant : Invent 2017 : Another Day, Another Billion Flows (NET405) – YouTube) qui crée un problème dans le scénario d’Overlay IP (ainsi que pour les instances NAT, cependant, cela n’est pas détaillé ici). Comme Overlay IP est une entité externe à l’instance EC2 et à son interface réseau, si l’instance EC2 aura cette vérification activée, elle bloquera éventuellement la transmission des paquets puisque la destination est l’IP de superposition.
Modèles de conception dans SAP qui exploitent l’IP de superposition — L’utilisation principale de l’IP de superposition dans les paysages SAP concerne les clusters d’applications (cluster ASCS/ERS) et le cluster de bases de données (principalement le cluster SAP HANA). Les applications SAP ont un modèle de conception où SAP ASCS, abrégé pour ABAP SAP Central Services and Database, sont des points de défaillance uniques. Pour assurer la résilience, il est recommandé de les rendre redondants et d’améliorer le temps de disponibilité de l’application, le basculement vers le nœud secondaire/de secours doit être effectué automatiquement et de manière transparente. Pour ce faire, les clusters sont généralement constitués de trois ressources :
1. Le composant d’application lui-même, ou en d’autres termes, le service qui doit s’exécuter et doit être surveillé
2. Le système de fichiers qui peut être monté pour exécuter ces services
3. Une adresse réseau, dans le cas d’AWS, est l’adresse IP de superposition qui peut être attribuée à un nœud de cluster actif.
Bien que la conception du cluster lui-même soit également une discussion détaillée en soi, pour l’instant, nous nous concentrerons sur la manière dont Overlay IP est utilisé dans les clusters. Le logiciel de cluster détermine quel nœud est actif en déterminant d’abord l’état du service SAP ou de la base de données qu’il surveille, puis en s’assurant que l’IP de superposition pointe vers la même instance EC2 où se trouve l’état actif actuel. Lorsqu’une panne est détectée, parallèlement aux services déplacés, l’IP de superposition se déplace également vers l’autre nœud EC2, garantissant ainsi que tout le trafic des applications et des utilisateurs finaux continue de fonctionner de manière transparente avec le nœud actif. Le cluster met également à jour les tables de routage et utilise l’agent Overlay IP pour cela. Je couvrirai l’agent Overlay IP lui-même dans un article de blog séparé.
La mise en œuvre de Overlay IP est disponible de deux manières différentes conformément à la recommandation AWS.
1. Transit Gateway — Un routeur virtuel ou un routeur cloud, comme l’appelle AWS. Ce composant est conçu pour fournir un routage entre plusieurs Amazon VPC et également pour les environnements sur site des clients qui sont connectés via VPN ou Direct Connect au réseau AWS. La table de routage Transit Gateway, dans ce cas, devrait essentiellement avoir une route où l’IP de superposition est ajoutée en tant que destination, la cible étant une instance EC2 faisant partie d’un cluster.
2. Équilibreur de charge réseau — Un équilibreur de charge réseau est essentiellement conçu pour l’équilibrage de charge TCP ; bien que les clusters dans SAP soient des configurations actives-passives et ne soient pas vraiment « équilibrés » dans un sens réel, le NLB est capable de choisir un cible du groupe cible NLB pour acheminer le trafic vers un destination qui est l’IP de superposition.
Voici l’instantané des ressources créé dans le cluster Pacemaker pour référence rapide :
primitive rsc_IP_HA1_ASCS00 ocf:suse:aws-vpc-move-ip \ params ip=xxxx \ routing_table=rtb-xxxxxxxxx,rtb-yyyyyyyyy,rtb-zzzzzzzzz \ interface=eth0 profile=cluster \ op start interval=0 timeout=180 \ op intervalle d’arrêt = 0 timeout = 180 \ intervalle de surveillance op = 60 timeout = 60
L’IP ici est l’IP de superposition, et la table de routage est celle qui est soit attachée au VPC en cas de configuration NLB, soit à la table de routage de la passerelle de transit si la passerelle de transit est utilisée.
Le cluster gère essentiellement l’adresse IP avec le paramètre de colocation du cluster, qui est défini pour être colocalisé avec la base de données principale HANA actuelle. La documentation d’AWS peut être utilisée pour la configuration réelle. Ce blog est destiné à fournir des détails techniques et de fond. Il est important de garder à l’esprit que l’agent Overlay IP remplace les entrées de la table de routage afin que le routage soit redirigé vers le nœud de cluster actif, et que les autorisations AWS IAM nécessaires pour celui-ci doivent être disponibles pour le profil IAM de l’instance AWS EC2 correspondante. .
D’un autre côté, ne comptez pas sur ChatGPT pour une réponse à cette question car il ne peut analyser que les données textuelles disponibles et fournir des réponses, et comme les données d’entrée sur Overlay IP sont limitées, les informations fournies sont actuellement inexactes et trompeuses.