Archives mensuelles : septembre 2016

Microsoft Experiences 2016 : Azure Stack de l’Azure dans votre Datacenter

Ca approche doucement, on peaufine nos derniers slides, affine nos démos, bref les Microsoft Experiences 2016, c’est bientôt.

Session

 

En ce qui me concerne, nous animerons avec Bruno Saille une session autour d’un produit qui nous tiens à cœur, à savoir Microsoft Azure Stack. Pour information, la session est planifiée pour la journée technique (donc le mercredi 5 octobre 2016). La session est planifiée pour le créneau horaire 18h15-19h00 en salle 252B. Nous serons donc disponible immédiatement après pour répondre à vos questions autour d’un verre.

Si Microsoft Azure Stack vous intéresse, l’évènement Microsoft Ignite devrait vous intéresser puisqu’il y a pas moins de onze sessions consacrées au sujet.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Découverte d’Azure VNet Peering

La période la plus difficile pour un addict du cloud, c’est les vacances, loin de ses régions Azure, … La qualité du réseau Corse n’incitant pas à la pratique assidue d’azure, il y a des sujets qui passent à la trappe. Le Vnet Peering est l’un d’entre eux. Le service est apparu pendant le mois de Juillet 2016 pour être visible dans le portail depuis le mois d’Aout 2016 : Public preview: VNet Peering for Azure Virtual Network

Avant, lorsqu’on voulait reproduire l’isolation réseau entre un environnement de production et les autres, le seul moyen à notre disposition était de segmenter avec plusieurs VNet et de connecter ceux-ci avec une Gateway comme illustré ci-dessous :

clip_image001

 

Cette approche répond parfaitement à notre problématique d’isolation. Par contre, elle présente plusieurs inconvénients :

  • Le coût : La mise en place de deux Gateway fonctionnant 744 heures par mois. Ce n’est pas négligeable.
  • La performance : Passer par deux Gateway, implique un tunnel IPSEC. Un fort trafic réseau entre les deux VNET impliquera de bien dimensionner les dites gateways car c’est le VCPU qui va travailler.
  • La logique : Pourquoi faudrait-il ressortir sur Internet pour connecter deux réseaux alors qu’ils sont dans la même région, donc dans le même datacenter

 

C’est pour répondre à ce type de problématique que Microsoft a introduit la notion de Peering. D’un point de vue conception, c’est tout de suite plus simple

clip_image002

 

Le Peering se configure dans le portail Azure depuis le 1er Aout 2016 comme illustré ci-dessous :

clip_image003

 

J’ai attendu que la fonctionnalité soit nativement disponible dans le portail, c’est plus simple. Un Peering est un objet dans Azure, il a donc un nom. Premier point intéressant, la fonctionnalité de Peering s’applique aussi bien aux VNets dits classiques (ASM) que ARM.

clip_image004

 

Un Peering peut être mis en place entre :

  • Deux VNets au sein de la même souscription
  • Deux VNets au sein de souscriptions différentes

 

La seule limite actuelle est que les deux VNets dépendent de la même région Azure. Ça tombe bien, c’est le cas de mes deux VNETs. L’option Virtual Network Access est intéressante. Elle permet de considérer l’autre VNet comme une extension du notre, donc inclus dans le Tag Virtual Network. Autant dire que pour un scénario de segmentation Production-Préproduction, on va éviter. Les trois dernières options permettent de maîtriser le routage :

  • Allow forwarded Traffic : Permet de maîtriser le flux réseau en provenance du partenaire (mais ne dépendant pas de son Vnet)
  • Allow Gateway transit : Permet à notre partenaire d’utiliser notre passerelle pour le routage du flux réseau externe
  • Use Remote gateways : Utilisé par notre partenaire pour qu’il puisse utiliser notre passerelle pour le routage de ses flux réseaux externes

 

Logiquement, pour que cela fonctionne, il faut créer un autre objet VNet Peering pour l’autre VNet, ce que j’ai fait.

clip_image005

 

Si on a pas l’overlapping d’adressage, alors le VNet Peering devrait apparaître ainsi dans les deux Vnets, avec la mention « Connected ».

clip_image006

 

Pour vérifier que cela fonctionne, on va tenter de communiquer depuis une machine virtuelle dont la carte réseau est connectée au réseau de pré-production pour joindre une machine virtuelle dont l’interface est liée au réseau de production. Voilà la configuration d’une machine virtuelle de pré-production. Elle dispose d’une Gateway sur son réseau, que du classique.

clip_image007

 

Et côté production :

clip_image008

 

Pour valider le bon fonctionnement, on va pinger depuis la machine virtuelle de pré-production vers la production.

clip_image009

 

Effectivement, cela fonctionne. On voit que c’est du VNet Peering car le TTL ne décroit pas. C’est logique car on ne passe pas par un routeur, c’est ce que nous confirme le Tracert.

Alors Vnet ou Gateway?

Pour certains scénarios (segmentation d’environnements), le VNet Peering est intéressant. Maintenant, reste à voir comment le service sera facturé lors de son passage en GA. Du point de vue Azure, on consommera nécessairement des ressources. On n’a plus les adresses IP publiques associées à nos Gateway ni le coût de compute de celles-ci mais il y aura forcément un coût. Sur le papier, le VNet Peering à tout pour plaire et supporte déjà beaucoup de fonctionnalités que nous utilisons souvent :

  • Network Security group
  • Network Virtual Appliances
  • User-Defined Routes
  • Internal Load-Balancers

 

Personnellement, je suis fan.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)