Spinnaker Networks, créateur de la solution de Cluster NAS SpinServer à base de SpinOS et SpinFS, fait aujourd'hui parti de la gamme Network Appliance. Acquis début 2004 pour 300M$, période de l'acquisition définitive, Spinnaker Networks fut un précurseur et un innovateur sur le segment étroit mais en forte croissance des clusters NAS ou NAS haut de gamme dits Evolutif ou Scalable. L'idée générale et simple, au moins sur le papier, était de constituer un service fichier évolutif linéairement, c'est-à-dire que la performance devait suivre l'ajout de serveurs, fait de pool de serveurs et de stockage le moins cher possible basé sur les protocoles de partage fichier standards de faits NFS et CIFS. Attention, l'offre ne se déclinait pas en couche logicielle à déployer sur une ferme standard de serveurs comme on peut le voir chez Ibrix par exemple. Ce segment est aujourd'hui trés actif avec BlueArc, Crosswalk, EMC, Exanet, Ibrix, Isilon, OnStor, Panasas ou Rackable Systems qui a absorbé TerraScale.
Historiquement tenté de développer sa propre solution sans réelle satisfaction et adoption marché, NetApp s'est donc penché vers ce qui se faisait de mieux sur le marché à ce moment. NetApp a souhaité ensuite intégrer SpinOS à Ontap - car tout tourne sous Ontap chez le constructeur de Sunnyvale - c'est dommage car le produit commercialisé à l'époque de Spinnaker a été d'un seul coup retiré du marché, frustrant pour ne pas dire plus les utilisateurs. NetApp a attendu le printemps 2006 pour dévoiler Ontap GX et l'option FlexVol HPO (High Performance Option), nous reviendrons sur cette option par la suite. Mike Kazar, ancien CTO et co-fondateur de Spinnaker, un des pionniers d'Andrew File System, est d'ailleurs toujours chez NetApp en tant que Chief Architect. Pour ma part, je suis particuliérement l'aventure Spinnaker Networks car je devais monter l'activité France en 2003, Jeff Hornung, alors VP Bus. Dev. du constructeur, souhaitait étoffer son équipe et attaquer le marché Européen, Jeff est aujourd'hui CEO et Président de Scentric, un des leaders de solutions de classification de données avec le produit Destiny, l'une des rares solutions à traiter des données non-structurées - simple fichier -, semi-structurées - messagerie - ou structurées - base de données - et que je place volontiers parmi les meilleures solutions sur ce segment.
Pour comprendre l'intérêt de NetApp pour Spinnaker et le virage effectué par le champion des Filers, nous devons détailler l'offre SpinServer. Cette offre s'appuit sur un OS propre SpinOS sur une infrastructure Intel et surtout sur un système de fichiers SpinFS permettant d'agréger les espaces de stockage issus des autres serveurs Spinnaker présents dans la grappe baptisée SpinCluster. Chaque serveur propose aux clients une double interface Gb Ethernet et s'interconnecte aussi avec ses homologues au travers d'une double connexion IP sur Gb Ethernet connectée a un réseau privé switché. Un serveur est ensuite connecté à son stockage par des HBAs Fibre Channel. Un SpinServer met en place une architecture distribuée SpinFS dont l'esprit est de servir la requête par le serveur qui la reçoit même si la donnée réside sur un autre serveur du SpinCluster. Tous les clients peuvent accéder à tous les serveurs agrégeant ainsi la bande passante réseau, les capacités de traitement des serveurs et le volume cumulé de stockage. Tous les serveurs voient l'ensemble des données par agrégation des espaces de nommage de fichiers mais un fichier n'appartient qu'à un seul serveur puisque ce fichier n'est accessible et présent que sur le stockage d'un seul serveur. Les serveurs constituant le cluster sont donc indépendants et l'évolutivité est garantie par simple ajout de serveur sans avoir besoin de répartir ou redistribuer les données entre toutes les machines. Plusieurs éléments clés sont donc nécessaires au bon fonctionnement de cette solution: la notion de Storage Pool, de Virtual File System (VFS), de Virtual Server, de Virtual Interface et de VFS Location DataBase ou VLDB.
Au sein de chaque serveur, on définit ce que l'on appelle un ou plusieurs Storage Pools que l'on peut assimiler à une partition virtuelle ou un volume logique avec un file system local. On crée ensuite des VFS, à ne pas confondre avec VFS/vnode des systèmes Unix, qui est une image logique de tout ou partie d'un file system physique avec sa racine et ses sous-répertoires. De fait, plusieurs VFS peuvent se partager un même storage pool lui même limité à un seul serveur mais un VFS appartient à un seul serveur, ce concept étant assez proche des volumes AFS ou des filesets DFS. On constitue ensuite un espace de noms global que l'on rend 
visible ou exporte à l'extérieur du cluster par le choix d'une racine et "monte" les autres VFSs sur ce premier espace constituant ainsi une vraie arborescence répartie sur plusieurs serveurs. La notion de Virtual Server regroupe le point d'export global associant les VFS et un nombre d'IP d'accès pour les clients. On aura compris que la VLDB - VFS Location DataBase - est fondamentale à l'efficacité de la solution puisqu'elle est chargée de renseigner en permanence un serveur quant à la localisation d'un fichier au sein du cluster, à quel serveur et donc Storage Pool ce fichier est rattaché. D'autres fonctionnalités intéressantes étaient là aussi plus ou moins abouties comme VFS Move pour déplacer des données entre serveurs, VFS Mirroring pour dupliquer des snapshots entre serveurs et un projet de partage de disques entre serveurs, rompant avec la philosophie de l'unité de stockage disque couplée à un seul serveur ou d'un VFS appartenant à un seul serveur, c'est-à-dire pourquoi ne pas striper les VFS entre serveurs.
visible ou exporte à l'extérieur du cluster par le choix d'une racine et "monte" les autres VFSs sur ce premier espace constituant ainsi une vraie arborescence répartie sur plusieurs serveurs. La notion de Virtual Server regroupe le point d'export global associant les VFS et un nombre d'IP d'accès pour les clients. On aura compris que la VLDB - VFS Location DataBase - est fondamentale à l'efficacité de la solution puisqu'elle est chargée de renseigner en permanence un serveur quant à la localisation d'un fichier au sein du cluster, à quel serveur et donc Storage Pool ce fichier est rattaché. D'autres fonctionnalités intéressantes étaient là aussi plus ou moins abouties comme VFS Move pour déplacer des données entre serveurs, VFS Mirroring pour dupliquer des snapshots entre serveurs et un projet de partage de disques entre serveurs, rompant avec la philosophie de l'unité de stockage disque couplée à un seul serveur ou d'un VFS appartenant à un seul serveur, c'est-à-dire pourquoi ne pas striper les VFS entre serveurs.
SpinOS et SpinFS pouvaient supporter 512 noeuds, un unique système de fichiers de prés de 11000 To (!!) et la dernière version de Data OnTap GX ne supporte que maximum 24 noeuds dans un cluster pour 6Po. Une vraie différence, dommage que Network Appliance souhaite toujours intégrer tout dans un seul produit, son système d'exploitation Data OnTap, car dans ce cas, ce fut laborieux et ce n'est toujours pas fini si NetApp souhaite atteindre les mêmes seuils pour 
pénétrer le marché du calcul scientifique. Néanmoins, GX joint les 2 esprits grâce à l'intégration de FlexVol, des snapshots, du mirroring et du RAID double-parité de mouture NetApp, le fameux RAID-DP. La grande nouveauté chez NetApp, dans les cartons chez Spinnaker Networks, est l'option FlexVol HPO, pour High Performance Option, permettant de striper ou répartir les écritures entre plusieurs serveurs de fichiers et non comme dans l'esprit historique de faire passer l'I/O par un seul serveur même si lui, derrière, effectue cette répartition sur ces unités de stockage. En montant d'un niveau, les clusters GX peuvent prétendre attaquer le marché du calcul scientifique, de la VOD ou des mondes numériques forts exigeants. NetApp a fait preuve là encore d'une bonne démarche et d'anticipation, certes longue, mais qui montre son avance et sa stratégie quand au rôle du stockage fichier dans le futur, Bravo.
0 commentaires:
Post a Comment