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.

Aujourd’hui viens une nouvelle version, la 0.2, première version que je considère comme stable et utilisable. Avec elle viens également un nouveau service sur inig-services.com, mes applications ! apps.inig-services.com

Pour informations, j’ai développé ce service avec le framework Django (python) et je l’héberge chez moi (d’où la lenteur de téléchargement, je n’ai qu’une freebox en campagne !). Pour résumer la chose, j’ai fait un webservice avec Django qui me fournit des informations sur la liste des applications disponibles ainsi que de leur version, le tout en XML. J’ai ensuite utilisé Dashcode pour créer une interface web. En effet dans sa version Snow Leopard, Dashcode dispose d’une série d’outils faits pour Safari Mac et permet de faire très simplement du parsing de fichier XML et des bindings sans avoir à écrire une seule ligne de JS, ce qui me correspond tout à fait !

J’ai nommé ce système AppCaster, en référence au format de flux appcast qu’il permet de générer. Lorsque je le jugerais assez abouti pour être utilisable par des tiers, je le mettrais gratuitement à disposition.

En attendant si un designer passe par la et veux refaire le frontend, qu’il ne se gène pas, je le distribuerais avec la release d’AppCaster le jour venu.

Vous retrouverez formulaire d’inscription et plan de conférence ici, merci de vous inscrire pour savoir si on passe acheter un pack de bière ou si l’on doit réserver Bercy pour la soirée !

Ce sera le jeudi 1er juillet sur Paris, à l’IRCAM. Pour plus d’informations je vous invite a vous référer au site principal.

À vos agendas messieurs (et mesdames !)

J’ai donc développé un petit logiciel (rien de bien méchant rassurez vous) qui viens compléter le manque de Server Admin.

Si cela vous intéresse, voici donc ce logiciel que je fournis actuellement a titre expérimental, il est en version 0.1 et pour tout vous dire je viens à peine de finir de le compiler. Pour autant ce petit outil, qui utilise exactement le même protocole que Server Admin, à très peu de chance de casser quoi que ce soit… Dans le pire des cas, vous n’aurez que les fichiers de config du NAT à remplacer. (Un petit backup de /etc/nat par exemple)

Pour information, j’ai testé mon logiciel sur un serveur 10.6, il doit également fonctionner sur 10.5. Pour ce qui est de 10.4 par contre je ne sais pas, à vérifier.

Je suis bien entendu intéressé par toutes critiques possibles et remontées d’erreurs :-)

NatConfig

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.

Suite à notre participation régulière aux sessions CocoaHeads Paris nous avons décidé de lancer un projet similaire pour nous, les administrateurs système Mac OS X.

Ainsi est né MacSysBrain, le groupe des administrateurs système Mac francophone. Ce groupe a pour objectif de se réunir tous les trimestres pour discuter de nos dernières trouvailles en matière d’administration. Les réunions s’articuleront autour de deux ou trois présentations suivies par un dîner.

Les réunions se feront un partout en France, la première aura lieu sur Paris par simplicité d’organisation, les suivantes se feront en fonction des possibilités d’hébergement. Il n’est absolument pas exclu de changer de ville tous les trimestres, c’est même l’objectif à court terme !

Administrateurs Mac OS X  de tous pays francophones unissez-vous !

Les dates de la première réunion ne sont toujours pas fixées. En effet nous attendons avec impatience celles de la WWDC. Les premiers sujets ne sont pas non plus fixés.

En attendant, MacSysBrain peut d’ores et déjà commencer à prendre du service via sa liste de diffusion fr@macsysbrain.com (inscription ici) et son site web.

Cette liste de diffusion vient en complément des autres communautés existantes et a pour but de regrouper tous les niveaux d’administrateur.

Elle est destinée à discuter de l’organisation des réunions. Elle n’a pas vocation à remplacer les listes des sites existantes qui remplissent très bien leur office.

Les personnes à l’origine de cette initiative sont Yoann Gini, formateur Certifié Apple depuis 2007 et consultant sur les technos Apple en entreprise (blog.inig-services.com) et Jacques Foucry, auteur de « Mac OS X Server à votre service (adminblog.foucry.net), tous deux bien connus de la communauté des administrateurs Mac OS X.

Nous tenons à remercier la société Aquaray qui héberge le site MacSysBrain et Dominique Baillon (développeur WebObjects) qui nous soutenu dans cette initiative.

C’est dans cette optique que le centre de formation Terkane propose deux semaines de formation en mai en vue de l’obtention de la certification ACSA.

Pour une fois cette formation ne sera pas donnée par moi-même, mais par un autre formateur. Je profiterais donc de cette occasion pour repasser de l’autre côté et suivre ces deux semaines de formation pour obtenir ma certification ACSA que je dois passé depuis 2 ans maintenant (pas encore fait, faute de temps).

Pour tous ceux qui sont intéressés, voici les liens utiles. La formation ACSA est découpée en 3 formations donnant lieux à une évaluation à chaque fois.

Directory Services + Deployment : Ces deux formations seront regroupées sur une seule semaine

Mobility & Security

En espérant avoir le plaisir de vous voir en formation !

Une dernière chose, si des admins de la région de Marseille, compétant sur OS X Server, lisent se message et ne souhaite pas assister à cette formation, merci de m’envoyer un mail. Un de nos collègues recherche une personne pour être présent à sa place chez un de ses clients, un jour pour chaque semaine.