Vous vous souvenez que, dans un précédent article, j’ai présenté la configuration assistée d’un Xsan. Dans cet article j’ai choisi de préparer un volume destiné à recevoir des mails, nous allons donc repartir de là et utiliser très simplement l’assistant de configuration du service mail pour voir ce que nous pouvons faire.

Dès le début, l’assistant repère la présence du Xsan et nous donne trois choix, un serveur mail standard, rejoindre un cluster mail existant ou en créer un nouveau.

À la suite de quoi, l’assistant de configuration vous demande de choisir le volume Xsan partagé entre les différents serveurs du cluster, ne vous seront proposés dans la liste que les volumes Xsan bien entendu.

Si vous disposez d’anciens serveurs, vous pouvez dans le même temps demander une migration des données existante.

Le reste de l’assistant correspond à ce que nous avons déjà eu l’occasion de voir à propos de la configuration du service Mail de Mac OS X Server.

La suite des opérations est assez simple, il suffit de gérer les autres serveurs, toujours avec Server Admin, pour leur dire de rejoindre un cluster existant.

Puis l’emplacement des données :

À la suite de quoi l’assistant se termine, il ne vous reste plus qu’à configurer le SMTP en vous demandant si ce serveur sert uniquement de connecteur POP/IMAP ou s’il est utilisé comme serveur SMTP ?

Voilà pour cette rapide introduction. Pour information, l’article a été rédigé avec deux Mac OS X Server 10.5 étant donné que les Xserves que j’ai à la maison sont des G4. C’est une des raisons pour lesquelles je ne rentrerais pas plus dans les détails pour cette fois.

D’après Apple Xsan est un système de fichier 64 bits en cluster, utilisable pour tout type d’environnement demandant un haut degré de rendement sur l’accès aux données.

Concrètement qu’est-ce que cela veut dire ? Le 64 bits concerne l’adressage de l’espace disque, bien que fondamentalement intéressant, nous allons plus discuter de la partie cluster. Généralement lorsqu’on parle de clusters en informatique, on pense directement au calcul distribué qui permet d’agréger un certain nombre d’ordinateurs autour d’un système d’exploitation spécifique en vue de former un super calculateur. Ici nous sommes dans le même cas, mais pour un système de fichier. Nous allons pouvoir agréger plusieurs disques ensemble pour en faire un gros, voir un très gros étant donné que la taille maximale d’un volume avec Xsan 2 est de 2Po, soit 2000 To…

L’autre avantage de cette technologie est que ces volumes managés par Xsan seront accessibles à plusieurs machines en même temps (64 au maximum) et à haute performance.

Xsan n’est qu’une vision spécifique d’un SAN (Storage Area Network). Pour bien comprendre la différence, revoyons nos cours élémentaires d’informatique, chapitre sur les différents types de stockage.

DAS, Direct Attached Storage : C’est le cas le plus simple, un disque dur branché directement à la machine via un bus SATA, USB, FireWire… Dans ce cas, l’accès disque est relativement rapide, mais restreint à une seule machine

NAS, Network Attached Storage : Bien que ce soit utilisé pour nommer ces disques durs réseau autonome, un NAS est tout simplement un DAS partagé à travers un réseau, Ethernet généralement, et nécessitant un protocole de partage (AFP, SMB, etc.). Le principal problème de cette solution étant le point de congestion représenté par la connexion réseau et ainsi que la mauvaise tolérance de panne. Si le système hébergeant le disque flanche, aucun autre ne peut prendre la relève sans intervention humaine.

SAN, Storage Area Network : Réseau spécifiquement dédié à l’échange de données et basé sur la technologie Fibre Channel qui permet l’échange de commandes SCSI à haute vitesse à travers une paire de cuivres, un câble coaxial ou une fibre optique.

Xsan fait donc partie des SAN ici. Mais ce qui va le différencier des autres est son aspect « cluster ». Mais continuons dans nos cours élémentaires au chapitre des SAN.

Dans un SAN nous avons plusieurs composants, entre autres les initiateurs SCSI (les ordinateurs) et les cibles (vos baies Promise & Xserve RAID). Éventuellement, vous aurez vos switchs, mais ce n’est pas le principal pour le moment. Dans un SAN des plus basiques, vous allez devoir configurer vos baies RAID pour créer vos espaces de stockage (c.-à-d. regrouper vos disques sous différentes formes de RAID pour les utiliser ensuite).

Ces espaces de stockage ainsi constitués sont identifiés par des numéros d’unité logique en SCSI, autrement appelés LUN. Prenez note de la métonymie, un LUN n’est qu’un identifiant et non le groupe de disques formant un RAID.

Une fois les baies RAID configurées, vous allez devoir assigner chaque LUN à un ordinateur spécifique qui s’en servira comme d’un DAS en quelque sorte. Exception faite de la vitesse de transfert disque/machine et de la taille possible de l’espace de stockage, nous nous retrouvons avec les mêmes limitations qu’un DAS, à savoir qu’il est affecté à une seule machine. L’explication en est simple, comment savoir si une autre machine ne cherche pas à accéder aux mêmes données en même temps.

C’est ici qu’entre en jeu l’aspect clusterisé du système de fichiers de Xsan. Dans cet environnement, il y aura des machines qui seront désignées comme contrôleur de métadonnées, leur rôle sera, entre autres, de garantir le fait qu’un fichier n’est écrit que par un seul client à la fois.

Histoire de ne perdre personne, la version illustrée différenciant SAN, Xsan :

Soit deux baies RAID différentes hébergeant chacun un seul LUN (les deux LUN pourraient être sur une seule baie, le fonctionnement serait le même). Si vous n’avez pas de système de fichiers clusterisé, vous devrez assigner un LUN à un serveur et ce dernier utilisera son driver standard pour gérer l’espace de stockage, pensant qu’il a en face de lui un RAID connecté sur un bus SCSI. Dans le cas de Xsan et des systèmes de fichiers en cluster, vous allez pouvoir désigner plusieurs LUN comme composants d’un volume unique. Pour que cela fonctionne, il vous faudra disposer du client Xsan sur vos serveurs, sans quoi ils seront incapables de retrouver leurs petits au sein du SAN.

Les présentations étant faites, regardons de plus près l’histoire des contrôleurs de métadonnées. Leur rôle est de gérer l’accès aux données. Il peut y avoir plusieurs serveurs dédiés à ce rôle, mais pour un volume donné, un seul est en activité, les autres attendent et ne prendrons la relève que si le principal tombe en panne.

Quand un client Xsan cherche à accéder à une ressource sur un volume particulier, il va consulter le contrôleur en lui demandant où se trouve la ressource et si l’utilisateur a le droit de l’utiliser. Le contrôleur principal va aller rechercher ces informations sur le SAN, sur un LUN spécifiquement dédié aux métadonnées, puis renvoie le tout au client. Ces métadonnées contiennent les informations de localisation des données (où sont elles physiquement ? Sur quel disque de quel LUN ?) ainsi que les propriétés du fichier (nom, droit d’accès, date de modification, etc.) Ainsi lorsqu’un client est en train de modifier un fichier, le contrôle est informé, lorsqu’un second client va faire une demande pour ce fichier, il pourra agir en connaissance de cause.

L’intérêt de placer ces métadonnées sur des LUN dédiés à cet usage est de rendre ces dernières accessibles aux autres contrôleurs. Ainsi lorsque le principal tombera, le prochain sur la liste prendra la relève sans perdre le fils des opérations.

C’est beau n’est-ce pas ?

Voici un exemple de liste de course pour mettre tout cela en place :

• Un minimum de deux serveurs et des clients (les serveurs sont tout à la fois des clients, vous pouvez donc n’avoir que des serveurs selon vos objectifs) équipés de carte FC ainsi que de deux cartes Ethernet, donc Xserve ou Mac Pro
• Une ou plusieurs baies RAID telles que la baie Promise validée par Apple ou encore le Xserve RAID qui n’est plus vendu (si vous testez une autre baie, sachez que ce n’est pas supporté par Apple)
• Un switch pour fabric SAN compatible de chez Cisco, Qlogic ou Brocade (voir la liste ici)
• Des câbles Fibre Chanel en cuivre (courte distance)
• Des émetteurs/récepteurs optiques, deux par câble optique (longue distance)
• Un switch Ethernet Gigabit supplémentaire pour créer un réseau dédié à l’échange de données entre clients et serveurs de métadonnées (pas obligatoire, mais fortement recommandé si vous cherchez la performance)
• Une licence Xsan par client

Pour vous éviter un tour sur l’Apple Store, le montage initiale avec deux Xserve pour un volume Xsan avec une baie promise de 32 To et un switch optique 8 ports revient environs à 30 000 € TTC, ce à quoi vous rajouterez quasiment 2000 € par Mac Pro que vous souhaitez raccorder au Xsan (en plus de la configuration initiale et de Final Cut par exemple).

Je vous laisse négocier les ristournes pendant que nous passons à la configuration de ce matériel de pointe.

L’intérêt de ce genre de manip est multiple, communiqué avec une baie Promise, un routeur Cisco, un Serveur, etc.

Un collègue à eu des problèmes de résolutions de nom sur la zone apple.com avec des serveurs gérant un Xsan, donc pensez à vérifier le comportement de vos serveurs dans ce cas précis.

Après investigation il apparait que le problème venait simplement de Server Admin qui avait mis à jour le champ reverse DNS du serveur en question pour l’assigner à swscan.apple.com, une vérification est donc de rigueur après modification du DNS.

L’autre problème que j’ai constaté se trouve sur la nouvelle fonctionnalité présente dans Snow Leopard, à savoir l’installation automatique des pilotes d’impression. En effet, ce système se sert de software update pour fonctionner et se trouve donc ici bloqué. Il faudrait regarder l’URL utilisée par ce système pour y placer un proxy sur notre faux swscan.apple.com local.

Si quelqu’un à des commentaires à ce sujet, n’hésitez pas à me les remonter.

Lorsque vous mettez en place une zone WAB en suivant mon tutoriel, serveradmin va reconfigurer BIND pour le placer sur le port 5030, un cat sur /etc/dns/options.conf.apple le confirme :

directory "/var/named";

forwarders { 8.8.4.4; 8.8.8.8; };

allow-transfer { none; };

listen-on port 5030 { 127.0.0.1; };

Et en réalité c’est dnsextd qui viens écouter sur le port 53 et qui retransmettra tout sur 127.0.0.1:5030 :

root@office ~ 19:07 % lsof -i 4 -nP | grep dnsextd dnsextd 111 root 4u IPv4 0x07246abc 0t0 TCP *:53 (LISTEN) dnsextd 111 root 5u IPv4 0x06f7020c 0t0 UDP *:53

Ce qui va poser un problème, à savoir les requêtes de transfert de zone…

yoanngini@office ~ 19:08 % host -t axfr office.inig-services.com Trying "office.inig-services.com" ; Transfer failed.
Trying "office.inig-services.com.office.inig-services.com"
Host office.inig-services.com.office.inig-services.com not found: 1(FORMERR) Received 12 bytes from 127.0.0.1#53 in 0 ms ; Transfer failed.

Et cela, même si BIND est correctement configuré :


zone "office.inig-services.com." { type master;

file "db.office.inig-services.com.";

allow-transfer {any;};

allow-update {none;};


Je dirais qu’à première vue, dnsexted bloque les transferts de zone. Je vous conseillerais donc de placer votre serveur WAB soit sur un serveur isolé soit sur votre serveur DNS secondaire.

A lot of french people have been interested by my documentation about Wide Area Bonjour, and this subject have no really good documentation, even in english. So I’ve decide, with the help of Laurent Pertois, to translate my documentation in english. You can download it at the end of this article.

A special thanks to Laurent for the translation of this doc!

Wide Area Bonjour

Cette fois-ci l’astuce ne viendra pas de moi, mais de mon distingué collègue Jacques Foucry qui nous explique cela sur son blog : OpenDirectory et sauvegarde.

Le très net avantage de sa solution de backup est d’utiliser les mécanismes intégrés de Server Admin et ainsi vous offre la possibilité d’un backup compatible avec l’interface standard de Server Admin !

En effet, si vous activez sur un de vos sites les services de changement de mot de passe et de gestion de mail, vous ne pourrez pas démarrer le service Software Update Server (SUS) sur son port par défaut, il sera déjà utilisé.

Avec cette configuration en place (sans SUS de lancé) voyons voir quels sont les ports utilisés :

root@office /etc/swupd 12:14 % lsof -nPi4 | grep 8088
Python    47236    _teamsserver    3u  IPv4 0x0a0496b0      0t0  TCP *:8088 (LISTEN)

Nous avons comme qui dirait une surprise ici

ps aux | grep _teamsserver
_teamsserver 47243   0.0  2.1  2542872  89628   ??  Ss   12:17PM   0:01.45 /usr/bin/python /usr/share/caldavd/bin/twistd --pidfile= -noy /usr/share/emailrules/application.tac
_teamsserver 47241   0.0  2.6  2557844 108152   ??  Ss   12:17PM   0:01.92 /usr/bin/python /usr/share/caldavd/bin/twistd -n -o --pidfile= wiki
_teamsserver 47236   0.0  1.6  2516204  69076   ??  Ss   12:17PM   0:01.12 /usr/bin/python /usr/share/caldavd/bin/twistd --pidfile= -noy /usr/share/passwordreset/application.tac

Autant dire que dans ces conditions il sera difficile d’avoir un serveur de mise à jour fonctionnel !

Pour ma part j’ai choisi de passer le serveur de mise à jour sur le port 8188 qui était disponible chez moi.

N’oubliez pas qu’une fois votre serveur de mise à jour fonctionnel vous pouvez le rendre utilisable de manière transparente en suivant cet article.

Voici le principe, Mac OS X, qu’il soit client ou serveur, utilise plusieurs serveurs pour gérer les mises à jour, celui qui nous intéressera ici est swscan.apple.com qui renvoie aux clients une liste de mise à jour sous forme de fichier xml. Dans cette liste se situe donc les mises à jour avec entre autre leur localisation, par exemple pour Apple les mises à jour son sur swcdn.apple.com.

L’idée ici va être de faire en sorte que notre serveur se fasse passer pour swscan.apple.com et redirige ainsi non pas sur swcdn.apple.com, mais sur notre propre serveur interne, mais cela uniquement pour nos clients, il ne faudrait pas que notre serveur de mise à jour tourne sur lui-même.

Différentes méthodes sont disponibles sur internet, la plus répandue propose de mettre en place deux serveurs dont un qui n’est pas relié à votre DNS interne. Cette solution ne me plais pas vraiment, elle limite les possibilités de ce serveur. Voici donc une solution que je viens de mettre en production chez moi, elle vous est donc proposée à titre d’exemple, je vous laisse le soin de la tester pleinement.

Je considère pour cet article que votre serveur de mise à jour est déjà opérationnel, je m’attarderais donc uniquement sur le hack du serveur DNS.

Ouvrez donc Server Admin et créé une nouvelle zone DNS pour swscan.apple.com. où vous rajouterez une entrée A pour le FQDN swscan.apple.com. pointant vers l’adresse IP de votre serveur de mise à jour.

De cette manière vos clients se verrons envoyé sur votre serveur en lieu et place du serveur d’Apple. Cependant, votre serveur de mise à jour écoute par défaut sur le port 8088 alors que les clients chercherons le port 80. Nous allons donc rajouter un site à notre serveur web qui écoute déjà sur le port 80.

Là aussi, plusieurs méthodes existent, la plus couramment proposé rajoute un site et configure des redirections pour chaque fichier servant d’index de mise à jour. Pour ma part je vais utiliser une méthode beaucoup plus rapide puisque mon serveur web et mon serveur de mise à jour se trouve sur le même disque. Je vais définir le même dossier racine pour mon faux swscan.apple.com que celui utilisé par le serveur de mise à jour.

Par défaut les mises à jour sont stockées dans /usr/share/swupd sauf si vous les avez déplacés sur un disque externe, dans ce cas je vous laisse retrouvé où vous les avez mises à l’aide de la configuration du service de mise à jour. Dans le dossier du service de mise à jour il y a un dossier html, c’est celui-ci qu’il faudra définir comme racine de notre nouveau site.

Rajoutons donc un site dans notre serveur web :

J’ai également modifié le fichier index par défaut bien que ce ne soit pas nécessaire pour les machines. J’ai placé ici index.sucatalog pour voir plus facilement si ma configuration marche.

Ainsi avec cette configuration, si vous vous rendez sur http://swscan.apple.com/ (avec éventuellement index.sucatalog à la fin) vous devez vous retrouver avec une page comme celle-ci :

Vous remarquerez en lisant le contenue que les mises à jour sont bien indiquées comme étant sur http://office.inig-services.com:8088/ qui est bien mon serveur de mise à jour.

Faites donc un test depuis vos clients, sous conditions qu’ils soient correctement configuré au niveau des serveurs DNS vous utilisez maintenant votre serveur interne !

Il reste une chose à faire maintenant, configurer votre serveur interne pour qu’il s’adresse bien au serveur externe d’Apple. Pour cela nous allons exploiter une fonctionnalité très intéressante de Mac OS X qui est le dossier /etc/resolver.

Ce dossier permet de spécifier un serveur DNS spécial pour un domaine précis (cf. Mac OS X Hints pour plus d’informations).

Par défaut ce dossier n’existe pas, nous allons donc le créer en tant que root et laisser les droits par défaut (rwxr-xr-x root:wheel) puis rajouter un fichier swscan.apple.com à l’intérieur qui contiendra ceci :

domaine swscan.apple.com
search_order 2
nameserver 8.8.8.8
nameserver 8.8.4.4
port 53

Cela indiquera à notre serveur que pour retrouver swscan.apple.com il doit consulter les DNS de Google.

Profitez de votre terminal en root pour faire un dscacheutil -flushcache et essayez donc d’ouvrir http://swscan.apple.com/content/catalogs/index-1.sucatalog depuis votre serveur !

Vous constatez bien que les URL de téléchargement ici renvois vers swcdn.apple.com, c’est donc que notre hack a fonctionné !

Vous pouvez aussi le voir en ouvrant l’application Software Update sur un client et sur le serveur et constater ainsi la différence de vitesse.

Une note cependant à propos du dossier resolver. C’est une fonctionnalité qui n’est pas forcément utilisée par les commandes unix, ainsi host ou dig vous renverrons la valeur de votre DNS local alors que le ping lui essayera bien de contacter le bon serveur.

Si vous avez des remarques concernant cette manipulation n’hésitez pas à laisser des commentaires.

Je rappelle également que ceci n’est pas un fonctionnement standard, vous êtes seul responsable de ce que vous faites, évitez par exemple de faire cette manipulation avec un serveur DNS qui peut être contacté depuis l’Internet…

Voyons voir maintenant comment faire en sorte que l’écriture sur cette zone soit protégée par un secret partagé.

English version

Vous vous souvenez certainement que dans le deuxième article de cette série nous avions utilisé une ligne de commande pour faire en sorte que la clef bonjourRegistration de notre zone WAB prenne la valeur open. Nous allons maintenant modifier cette valeur pour la mettre à secure.

root@office / 18:17 % serveradmin settings dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:bonjourRegistration = "secure"

Cette commande à un effet sur le fichier /etc/dns/publicView.conf.apple qui contient la définition de nos domaines géré. Regarder votre zone WAB, elle devrait ressembler à ceci :

	zone "bonjour.office.inig-services.com." {
		type master;
		file "db.bonjour.office.inig-services.com.";
		allow-transfer {none;};
		allow-update {key com.apple.ServerAdmin.DNS.bonjour.sharedSecret;};
	};

L’intéressant ici se trouve sur la ligne allow-update qui est réglé par Server Admin pour utiliser uniquement la clef com.apple.ServerAdmin.DNS.bonjour.sharedSecret. Il nous reste donc à définir cette clef puis à la transmettre sur nos clients.

Pour définir cette clef, l’outil à utiliser en ligne de commande est rndc-confgen, il va également falloir lui indiquer où stocker la clef, pour ma part j’ai choisi /etc/dns/bonjour.key.

root@office / 18:27 % rndc-confgen -a -c /etc/dns/bonjour.key -k com.apple.ServerAdmin.DNS.bonjour.sharedSecret

Si vous regardez le contenue de ce fichier vous devez avoir quelque chose de ce genre :

key "com.apple.ServerAdmin.DNS.bonjour.sharedSecret" {
	algorithm hmac-md5;
	secret "lasZZ9TN+AILCl+TpNgUiw==";
};

Notez donc le secret entre guillemets, il vous servira sur les machines clients.

Cette clef étant générée, il reste à indiquer à Bind où elle se trouve, pour cela nous allons modifier le fichier /etc/named.conf pour faire en sorte que le début ressemble à cela :

//
// Include keys file
//
include "/etc/rndc.key";
include "/etc/dns/bonjour.key";
 
// ...

Il ne vous reste plus qu’à redémarrer le service DNS :

root@office / 18:33 % serveradmin stop dns && serveradmin start dns

Il nous reste ici à configurer les machines clientes, rendez-vous dans les préférences systèmes, section partage pour aller configurer l’enregistrement WAB de votre client en utilisant com.apple.ServerAdmin.DNS.bonjour.sharedSecret comme nom d’utilisateur et lasZZ9TN+AILCl+TpNgUiw== comme mot de passe.

Vous savez déjà comment vérifier que votre zone fonctionne, Bonjour Browser est votre ami :-)