Les différents types de nuages

Après avoir tenté de définir le cloud computing et avoir évoqué les différentes technologies associés, nous allons nous intéresser aux différentes offres. Nous nous intéresserons à toutes les offres de la nature qui revendiquent un caractère de « cloud computing ».

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.

Quelques outils de diagnostic DNS

Le DNS (Domain Name System) est un service exceptionnellement critique de n’importe quel réseau et de l’Internet. Cette semaine, j’ai eu l’occasion de plancher sur de nombreuses problématiques DNS dans le cadre de la fusion de deux serveurs DNS assez conséquents.

Dans cet article, je parlerais uniquement de BIND car il s’agit de la référence en terme de serveurs DNS. Je supposerais également que vous utilisez Linux. Et oui, BIND ça fonctionne également sous Windows. Je l’ai même déjà en production sur du Windows… Cela fait un petit pincement au coeur je vous assure.

dig

Le premier outil totalement indispensable est la commande dig. Elle permet d’interroger sélectivement des serveurs DNS. De plus, elle affiche une bonne quantité d’information quant à la requête effectuée. Cette commande sera donc particulièrement utile pour vérifier le bon fonctionnement de votre serveur DNS.

antoine@ks:~$ dig @ns0.infoclip.fr www.infoclip.fr
; <<>> DiG 9.3.4-P1.2 <<>> @ns0.infoclip.fr www.infoclip.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47195
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;www.infoclip.fr.               IN      A
;; ANSWER SECTION:
www.infoclip.fr.        86400   IN      A       217.25.177.18
;; AUTHORITY SECTION:
infoclip.fr.            86400   IN      NS      ns0.infoclip.fr.
infoclip.fr.            86400   IN      NS      ns1.infoclip.fr.
;; ADDITIONAL SECTION:
ns0.infoclip.fr.        86400   IN      A       217.25.176.28
ns0.infoclip.fr.        86400   IN      AAAA    2001:1650:0:1001::2
ns1.infoclip.fr.        86400   IN      A       194.29.206.67
;; Query time: 5 msec
;; SERVER: 217.25.176.28#53(217.25.176.28)
;; WHEN: Fri Feb 12 10:23:54 2010
;; MSG SIZE  rcvd: 145

host

La commande host est un outil particulièrement utile pour créer des scripts utilisant des informations DNS. Elle permet d’afficher très simplement des informations en rapport avec un nom de domaine telles que les serveurs DNS d’autorité, les MX ou le SOA.

antoine@ks:~$ host -t MX lemonde.fr

lemonde.fr mail is handled by 5 smtp0.lemonde.fr.

lemonde.fr mail is handled by 10 smtp1.lemonde.fr.

antoine@ks:~$ host -t ns lemonde.fr

lemonde.fr name server nsc.bookmyname.com.

lemonde.fr name server nsa.bookmyname.com.

lemonde.fr name server nsb.bookmyname.com.

antoine@ks:~$ host -t soa lemonde.fr

lemonde.fr has SOA record nsa.bookmyname.com. hostmaster.bookmyname.com. 1265963399 43200 3600 604800 3600

named-checkconf

L’outil named-checkconf est fourni avec BIND par défaut mais semble relativement peu connu. Cet utilitaire permet de vérifier la syntaxe d’un fichier de configuration. En sachant que BIND est assez peu tolérant des erreurs, cet outil vous évitera quelques mauvaises surprises.

named-checkconf /etc/named.conf

named-checkzone

Une fois que la configuration de BIND est correcte, il est intéressant de vérifier les zones. Je pense que cette vérification doit être périodique car les erreurs passent facilement inaperçue dans les zones. Cet utilitaire va vérifier la syntaxe de vos zones.

named-checkzone domaine.tld /var/named/domaine.tld

Au final, je pense que ces quelques outils devraient vous permettre de pouvoir mieux diagnostiquer d’éventuels soucis de résolutions de noms de domaine.

Cloisonnement d’un réseau à l’aide de VRF : BGP

Tout d’abord, je souhaite vous souhaiter de bonnes fêtes car c’est la période de l’année habituelle pour le faire. J’espère également que le père Noël aura été généreux en jouets et gadgets électroniques de tous genres. Je vais profiter de cette journée calme au travail afin de vous écrire le dernier épisode de cette série d’article.

Rappel des épisodes précédents

Dans le premier épisode, je vous ai présenté l’architecture réseau qui avait été mise en place ainsi que les équipements. Nous avons également vu l’objectif que nous cherchions à atteindre. Pour rappel, l’objectif était de faire du cloisonnement de réseaux tout en gardant la possibilité de partager des routes entre ces réseaux. C’est pour cela que nous avions choisi d’utiliser les VRF.

Dans le second épisode, nous avons fait la création des VRF ainsi que la configuration IP des interfaces associées.

Protocole de routage : BGP

A la suite de ces deux épisodes précédents, nous avons une configuration IP basique. Afin d’atteindre l’objectif que nous nous étions fixé, il va être nécessaire de partager les routes entre les différentes VRF. Il ne suffira pas de partager toutes les routes à tout le monde car dans ce cas-là les VRF n’aura pas grand intérêt. Nous allons propager les routes de manière sélective.

Le protocole de routage permettant de propager les routes de manière très sélective parmi des VRF est le BGP. Ce protocole de routage ne sert pas uniquement à cela, loin de là. Le BGP est entre autre le protocole de routage utilisé par tous les routeurs de bordure d’Internet afin de propager la totalité des routes de l’Internet. Nous en utiliserons qu’une petite fonctionnalité dans le cas présent.

Afin de pouvoir propager les routes de manière sélective, il va être nécessaire de se baser sur un critère de sélection. Vous vous rappelez surement des « Route Distinguisher » ou RD. Les RD sont une sorte d’étiquettes appliquée aux routes d’une VRF spécifique. Nous allons donc pouvoir choisir les routes que nous propagerons et celles que nous propagerons pas.

Le schéma suivant récapitule les échanges de routes que nous allons effectuer.

Configuration des VRF

Nous allons donc configurer les VRF avec les import / export que nous avons défini dans le schéma ci-dessus. La configuration des VRF est assez explicite. Je ne pense pas qu’il soit possible de détailler plus que cela.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# route-target export 200:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# route-target export 300:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# route-target export 100:1

ROUTEUR2(config-vrf)# route-target import 200:1

ROUTEUR2(config-vrf)# route-target import 300:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# route-target export 400:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 200:1

ROUTEUR2(config-vrf)# route-target import 300:1

Configuration du BGP

Nous allons maintenant configurer le BGP afin de faire la distribution de route que nous souhaitons. Dans le cadre de la configuration de BGP, il sera nécessaire de définir une « address-family » par VRF. Une « address-family » est un groupe de configuration qui va permettre d’appliquer des directives spécifiques à un groupe de routes.

ROUTEUR2(config)# router bgp 1

ROUTEUR2(config-router)# no auto-summary

ROUTEUR2(config-router)# address-family ipv4 vrf prod

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf interco

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# redistribute static

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf client1

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf client2

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

Cette configuration va nous permettre donc de propager les routes entre nos VRF. La prise en compte des modifications n’est pas forcément instantanée et peut prendre quelques minutes. Une fois le BGP configuré de cette sorte, il ne nous manque plus qu’une route : la route par défaut. Le BGP n’est pas un protocole réfléchi pour propager des routes par défaut. Il est cependant possible de lui forcer la main pour qu’il le fasse tout de même.

ROUTEUR2(config)# router bgp 1

ROUTEUR2(config)# default-information originate

ROUTEUR2(config-router)# address-family ipv4 vrf interco

ROUTEUR2(config-router)# default-information originate

Vous devriez voir toutes les routes appropriées dans les bonnes VRF. Les VRF clientes doivent donc avoir les routes vers les réseaux de prod et d’interco mais pas l’autre client. Les VRF d’interco et de prod doivent avoir une route vers l’un, l’autre et les VRF clientes.

Cet article clot la série des billets sur le cloisonnement de réseaux par le biais des VRF Cisco. Je vous ai uploadé les configuration que j’ai fait : Routeur1 & Routeur2.  Si vous avez des questions ou que vous pensez qu’il y a des imprécisions, n’hésitez pas à me le signaler par le biais des commentaires. J’espère que ce tutoriel vous aura été utile.

Cloisonnement d’un réseau à l’aide de VRF : Mise en place

stepfinal2Ce billet fait suite au premier billet traitant du sujet du cloisonnement d’un réseau à l’aide de VRF. Le premier billet avait pour objectif dans présenter la plateforme d’expérimentation que nous avons mis en place. Dans ce billet, nous allons nous intéresser à la configuration basique des équipements Cisco que nous avions à notre disposition. Dans un troisième et dernier billet, je présenterais la configuration du BGP permettant le propagation de routes sélectives entre les différentes VRF.

A titre de rappel, je vous renvois vers le précédent billet pour le schéma topologique qui vous permettra de comprendre plus facilement les configurations effectuées ici.

Configuration basique

Afin de pouvoir se retrouver plus facilement parmi tous nos équipements, nous allons paramétrer le nom d’hôte de nos différents équipements conformément au schéma.

ROUTER(config)# hostname ROUTEUR1

ROUTER(config)# hostname ROUTEUR2

Nous allons ensuite configurer les différentes interfaces IP de notre routeur de tête précédemment nommé ROUTEUR1.

ROUTEUR1(config)#interface Fa0/0

ROUTEUR1(config-if)#no ip address

ROUTEUR1(config-if)#shutdown

ROUTEUR1(config-if)#interface Fa0/1

ROUTEUR1(config-if)# ip address 192.168.100.1 255.255.255.0

ROUTEUR1(config-if)#exit

Nous allons ensuite configurer les routes statiques vers les réseaux raccordés directement sur notre second routeur. Il serait possible d’utiliser un protocole de routage mais par simplicité, nous avons choisi d’implémenter des routes statiques.

ROUTEUR1(config)# ip classless

ROUTEUR1(config)# ip route 192.168.0.101.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.102.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.103.0 255.255.255.0 192.168.100.2

La configuration de ce premier routeur se résume à ces commandes simples. Ce routeur est essentiellement un routeur témoin qui nous permettra de valider nos tests.

Configuration des VRF

Nous allons ensuite nous attaquer à la configuration des VRF sur notre second routeur. Pour rappel, les VRF sont des instances de tables de routage. Nous allons créer une VRF par zone de notre schéma. Nous en avons donc distingué 5 : client1, client2, prod et interco. Chaque zone aura donc sa propre VRF ce qui nous permettra d’avoir un cloisonnement finement paramétrable.

Tout d’abord, nous allons donc créer les VRF. Nous attribuerons un « Route Distinguisher » ou RD à chaque VRF. Un RD est un identifiant unique permettant d’identifier les routes associées à une VRF. Nous nous baserons sur ce critère lorsque nous ferons de la propagation de routes entre les différentes VRF.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# rd 200:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# rd 300:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# rd 100:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# rd 400:1

Une fois toutes les VRF créées, nous allons configurer les différentes interfaces selon le schéma défini préalablement.

ROUTEUR2(config)# interface Fa0/0

ROUTEUR2(config-if)# description OUTBOUND

ROUTEUR2(config-if)# ip vrf forwarding interco

ROUTEUR2(config-if)# ip address 192.168.100.2 255.255.255.0

ROUTEUR2(config)# interface Fa0/1

ROUTEUR2(config-if)# description PROD

ROUTEUR2(config-if)# ip vrf forwarding prod

ROUTEUR2(config-if)# ip address 192.168.101.1 255.255.255.0

ROUTEUR2(config)# interface Fa1/0

ROUTEUR2(config-if)# description CLIENT1

ROUTEUR2(config-if)# ip vrf forwarding client1

ROUTEUR2(config-if)# ip address 192.168.102.1 255.255.255.0

ROUTEUR2(config)# interface Fa2/0

ROUTEUR2(config-if)# description CLIENT2

ROUTEUR2(config-if)# ip vrf forwarding client2

ROUTEUR2(config-if)# ip address 192.168.103.1 255.255.255.0

ROUTEUR2(config)# ip route 0.0.0.0 0.0.0.0 192.168.100.1

Nous avons donc configuré les différentes interfaces, les différentes VRF ainsi que l’association des VRF aux interfaces. Si nous n’avions pas eu suffisamment de ports physiques, il vous est tout à fait possible de créer des sous-interfaces 802.1Q qui fonctionneront de manière identiques aux interfaces physiques.

Dans le prochain billet, je détaillerais la configuration du protocole de routage afin de redistribuer les routes de manière sélective parmi toutes nos VRF.

Articles de la série

Retour sur le Barcamp du 28 Novembre

barcamp_icon_finalJe vous avais parlé du barcamp qui a eu lieu à Troyes le week-end dernier dans un précédent billet. Je vais donc faire un petit retour sur cet événement.

L’objectif fixé était de faire un barcamp ouvert aux extérieurs tout en passant un bon moment au milieu de l’UTT Lan Session. Je pense que nous avons réussi cet objectif à l’exception que nous n’avons pas réussi à attirer beaucoup d’extérieurs. En même temps, nous n’avons pas beaucoup essayé je le reconnais.

Les sujets présentés sont les suivants : OAuth & OpenID, VBA pour Excel, SOAP pour Buckutt, Réseaux de stockage, LDAP, Trap your process et la CNIL. Nous avons donc eu une liste de sujets plutôt variés. Au niveau du timing, nous avons été plus ou moins fidèle à ce qui a été prévu. Certains présentations ont pris beaucoup de temps que prévu mais cela a compensé pour celles qui avaient été plus courtes.

Vous pouvez retrouver la présentation sur OpenAuth & OpenID en cliquant sur le lien ci-dessus. Vous pouvez trouver ma présentation ci-dessous.

Vous l’aurez compris, nous tirons un bilan tout à fait positif de ce barcamp. Nous prévoyons de réitérer cette expérience par la suite. Pour le prochain barcamp, nous le ferons dans les règles de l’art et essayerons d’attirer un maximum d’extérieurs.

Configurer un switch Cisco sous MacOS

CISCO LOGOCela fait désormais un an que je suis utilisateur assidu de MacOS. J’ai toujours réussi à faire ce que je faisais sur PC sur MacOS à quelques exceptions près. Ces deux exceptions sont les jeux 3D spécifiques Windows (Flight Simulator entre autre) et l’administration d’un équipement réseau via port série.

Les MacBook Pro ne sont pas dotés d’un port série. J’ai donc du commander un adaptateur USB-Série sur Ebay pour une somme tout à fait correcte dont je ne me souviens plus. On en trouve actuellement pour moins d’une dizaine d’euros. Vous allez cependant devoir vous armer de patience car ils sont le plus souvent expédiés de Chine. Voici à quoi ressemble ce fameux adaptateur.

usbserie

Il fonctionne parfaitement sous Ubuntu. Je n’ai eu aucune difficulté particulière. Une simple recherche Google et l’installation d’un driver a suffit pour le faire fonctionner. Je souhaitais cependant le faire fonctionner sur mon MacBook car il est quand même bien plus pratique de déplacer un portable qu’une tour.

La première action à effectuer est de récupérer le pilote adapté à l’adaptateur que vous avez acheté. Le problème est qu’il n’y a strictement rien marqué dessus. Ayant précédemment fait l’installation sous Ubuntu, j’avais réussi à déterminer qu’il s’agissait d’un PL2303. Ces adaptateurs semblent très répandus. Il y a donc beaucoup de chances que si le votre ressemble au mien, ce soit la même chose. Vous trouverez le pilote du PL2303 sur le site d’Apple. Vous allez devoir redémarrer votre poste pour finaliser l’installation du pilote.

Ensuite, il va falloir se connecter au périphérique que vous avez raccordé à l’autre bout de votre câble série. Sur Windows, vous auriez eu HyperTerminal qui remplit très bien ses fonctions. Sur MacOS, il est visiblement possible de faire fonctionner Minicom. Je n’ai pas du tout réussi… Fink et apt-get n’ont pas réussi à le trouver dans leurs dépôts. Je me suis donc lancé dans l’utilisation de screen. Dans mon cas, mon adaptateur était reconnu sous le nom /dev/cu.PL2303-00002006.

Il va falloir aller configurer les paramètres du port série du système. Dans le fichier /etc/gettytab, vous devriez trouver des lignes commencant par « serial. « . Effacez (ou commentez) toutes celles ne contenant pas 9600. Sauvegardez le fichier et exécuter la commande suivante :

stty -f /dev/cu.serial

Si la première ligne de la réponse est « speed 9600 baud; », votre port série est bien configuré. Vous pouvez ensuite accéder au périphérique en exécutant la commande suivante :

screen /dev/cu.PL2303-00002006

Vous devriez pouvoir accéder à votre périphérique. Une fois que vous aurez fini la configuration, vous pouvez quitter le screen en tapant « Cmd A » puis « Cmd . ».

Je pense que ce tutoriel devrait être utile à quelques personnes car cette configuration n’est pas forcément aisée à faire. Je me suis aidé d’un sujet sur le site d’Apple et d’un tutoriel du site MacOSHints.