storiq logo

La traînée de poudre

Le blog StorIQ

 

Lundi, 09 juillet 2018

ZFS : les bases et les pièges

ZOL

Depuis la disponibilité officielle de ZOL (ZFS on Linux) dans la dernière version stable d’Ubuntu, la mode ZFS bat son plein. ZFS est régulièrement présenté depuis de longues années comme la plus belle invention depuis les systèmes de fichiers journalisés.

ZFS il est vrai a de grands avantages: sécurité par l’utilisation systématique de sommes de contrôles en lecture comme en écriture, clichés (snapshots) continus, extension facile, virtualisation des volumes, différents niveau de redondance (miroir, RAIDZ, RAIDZ2, RAIDZ3…), déduplication, etc.

Mais si ZFS a ses avantages, il est nettement orienté vers l’administrateur système compétent, et fournit une ample réserve de fusils à pompe chargés à chevrotine (voire de lance-roquettes) pour se tirer des balles dans le pied. En particulier, de nombreuses manipulations irréversibles ou destructrices de données sont appliquées sans confirmation préalable aucune.

Passons ces points en revue.

Vocabulaire

Avant d’installer ZFS, il convient de se familiariser avec ses concepts. ZFS regroupe plusieurs fonctionnalités habituellement partagées entre plusieurs sous-systèmes, à savoir (sous Linux seulement):

  • la redondance (RAID)
  • les volumes logiques (LVM)
  • le système de fichiers.

Dans la tradition d’administration système Linux, pour obtenir la redondance on créera un volume RAID; pour pouvoir facilement redimensionner des volumes, attribuer des espaces de stockage dédiés à différents usages, prendre des clichés on utilisera LVM; enfin, on installera sur les volumes des systèmes de fichiers.

ZFS amène sa propre logique: on assemble les disques en vdevs, qu’on ajoute à un zpool, qu’on peut partager en volumes (sous-volumes, zvol ou clichés). La redondance (niveau de RAID) se fait au niveau du vdev, mais les clichés se font au niveau du zpool.

ARC, L2ARC et ZIL

ARC est simplement le cache disque de ZFS (dédié). Il n’utilise pas le cache VFS standard du noyau Linux.

L2ARC est un cache en lecture sur SSD. Il permet d’accélérer certaines lectures (aléatoires, petits fichiers…). Les SSD peuvent être relativement bas de gamme, et ils sont stripés.

ZIL est un cache en écriture sur SSD. Il permet d’accélérer les écritures synchrones et/ou aléatoires. Il faut des SSD très rapides, et en miroir. C’est un pur cache en écriture pour des reprises rapides en cas de coupure, etc.

Utilisation de base : créons un zpool

Un vdev est un ensemble de disques (une grappe RAID). Quand on ajoute des disques à un zpool on crée un nouveau vdev avec ces disques. On ne peut pas rajouter de disques à un vdev existant.

Commençons avec une machine sans pools:

# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   7,3T  0 disk 
sdb           8:16   0   7,3T  0 disk 
sdc           8:32   0   7,3T  0 disk 
sdd           8:48   0   7,3T  0 disk 
sde           8:64   0   7,3T  0 disk 
sdf           8:80   0   7,3T  0 disk 
sdg           8:96   0   7,3T  0 disk 
sdh           8:112  0   7,3T  0 disk 
nvme0n1     259:0    0 119,2G  0 disk 
  nvme0n1p1 259:1    0  29,8G  0 part /
  nvme0n1p2 259:2    0   1,9G  0 part [SWAP]
  nvme0n1p3 259:3    0  87,6G  0 part 

# zpool list
no pools available

Créons le zpool:


# zpool create poolz2 raidz2 sda sdb sdc sdd sde sdf sdg sdh

# zpool list
NAME     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
poolz2    58T   224K  58,0T         -     0%     0%  1.00x  ONLINE  -

# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev                16G       0   16G   0% /dev
tmpfs              3,2G     11M  3,2G   1% /run
/dev/nvme0n1p1      30G    5,7G   23G  21% /
tmpfs               16G       0   16G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs               16G       0   16G   0% /sys/fs/cgroup
tmpfs              3,2G    4,0K  3,2G   1% /run/user/117
tmpfs              3,2G       0  3,2G   0% /run/user/0
poolz2              40T       0   40T   0% /poolz2

# zpool status
  pool: poolz2
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        poolz2      ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     ONLINE       0     0     0
            sdh     ONLINE       0     0     0

errors: No known data errors

Les pièges de la création de zpool:

  • il est impossible de retirer un périphérique d’un zpool. Ceci induit deux corollaires:
    • si on se trompe et qu’on met un disque par erreur dans un zpool, par exemple une clef USB, tant pis: ce périphérique doit rester en place aussi longtemps que le zpool sera utilisé…
    • si on se trompe et que le disque inséré contenait des données, tant pis: elles sont irrémédiablement perdues, et ZFS ne demande pas de confirmation.

Conclusion: vérifiez très soigneusement la liste des disques que vous comptez utiliser avant de créer votre zpool.

Création de volumes

ZFS permet de créer très facilement des volumes (simples, ou clichés) à l’intérieur d’un zpool, et les monte automatiquement:

# zfs create poolz2/myshare

# cd /poolz2/myshare/
# ls
# mkdir test/
# mkdir titi tete tata toto
# for i in *; do echo rere > $i/rere; echo zeze > $i/zeze; done
# ls
tata  test  tete  titi  toto
# df -h .
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
poolz2/myshare      57T    128K   57T   1% /poolz2/myshare

par contre, attention au piège: la destruction d’un volume se fait sans le moindre préavis, ni demande de confirmation.

# cd
# zfs destroy poolz2/myshare 
# ls /poolz2/

Conclusion: avant d’utiliser la commande “zfs destroy” soyez très prudent.

Agrandissement de zpool

Il est extrêmement simple d’ajouter un nombre quelconque de disques à un zpool existant:


# zpool add poolz2 raidz2 sdi sdj sdk sdl sdm sdn sdo sdp 

Un piège lié aux précédents se présente lors de l’ajout de disques à un zpool. On serait tenté de croire qu’on peut y rajouter des disques pour l’agrandir au fur et à mesure, et effectivement si on y ajoute un disque ou deux, ZFS agrandira le zpool mais en créant un nouveau vdev à chaque ajout. Or le RAID se fait au niveau du vdev et pas au niveau du pool!

  • on ne peut pas ajouter de disques à un vdev, sauf à convertir un vdev d’un seul disque en miroir.
  • si on fait du raidz2, on doit ajouter les disques par vdev entiers, par exemple par groupes de 6, 8 ou 10 disques, faute de quoi la performance sera gravement impactée.

Un autre piège est que ZFS ne permet pas, contrairement au RAID logiciel Linux ou à la plupart des contrôleurs matériels, de changer le niveau de RAID d’un vdev ou d’étendre un vdev. Donc…

  • si on oublie un disque (on en met 9 au lieu de 10): dommage, il faut casser le zpool et le refaire. J’espère que vous n’y aviez pas encore mis de données…
  • si on se trompe de niveau de RAID : là encore c’est bien dommage, il est impossible de modifier un vdev.

Enfin, le piège mortel:

Si on perd un vdev, on perd tout le pool. Si on crée un pool avec un vdev raidz2 et qu’on ajoute un seul disque au pool, ce disque constitue alors un vdev non redondant. Si ce disque tombe en panne, tout le pool est perdu! Cas d’école: sur un serveur avec un zpool contenant 3 pétaoctets de données, on ajoute par erreur une clef USB au zpool. Quelqu’un retire la clef USB. Toutes les données sont perdues.

Clichés

Cela devrait aller sans dire et pourtant, il peut être utile de le répéter : les clichés (snapshots) ne constituent pas des sauvegardes. Un cliché fait partie du même zpool que le volume qu’il réplique : en cas de panne du zpool, les données originales aussi bien que les clichés seront perdues… Faites des sauvegardes!

Pour finir

ZFS est un système complexe pensé par et pour des administrateurs Unix chevronnés, binoclards et barbus qui méprisent les interfaces graphiques. dilbert Unix

Il n’est sûrement pas destiné aux “mangeurs de quiche”. Soyez prudents et extrêmement méthodiques en utilisant toute commande commmançant par “zpool” ou “zfs”.

lorsque vous créez ou agrandissez un zpool, vérifiez, vérifiez encore, testez, simulez. La moindre erreur peut causer des pertes massives de données…

posté à: 17:04 permalink

Lundi, 28 mai 2018

The Great Cloud Filesystems Shoot-out, Round 1: LizardFS

LizardFS is a Free Software cloud file system being developed since 2012. It was originally derived from MooseFS, and unlike MooseFS there are no restricted features in the OSS version (high availability metadata server, advanced redundancy management).

Architecture

The file system is structured in a classic way. The different components are:

  • the “Chunk Servers” who provide the actual storage. Storage is based on a standard local file system.
  • a “Master Server” which takes on the classic role of a metadata server, which manages object naming, access and client orientation to the “chunk” server containing the required data.
  • a “Metalogger Server” which manages a list of the operations in progress in order to be able to resume on incident in the event of sudden shutdown of the “Master Server”.
  • optionally, one or more “Shadow Servers” which are backup metadata servers, in order to be able to take over from the “Master Server” in the event of a problem.
  • and finally the FUSE client which allows to mount the file system locally.

Of course a physical server can simultaneously assume the functions of “Chunk Server” and “Master”, “Metalogger” or “Shadow Server”, as well as being a client.

LizardFS cluster

Local storage will typically rely on RAID arrays. Redundancy at the server cluster level will therefore be added to any local RAID redundancy.

The cluster configuration is quite simple and described in the LizardFS documentation.

Note that it is very easy to set different security modes for different parts of the overall file system. Granularity is done at the folder or even file level.

User Interface

LizardFS is used with fairly simple command line tools, and provides a convenient web interface to monitor the status of the cluster in all its aspects.

The administration essentially uses the lizardfs and lizardfs-admin commands to modify the cluster parameters.

The lizardfs-admin command communicates with the Master Server to change global parameters, for example:

lizardfs-admin list-goals [master ip] [master port]

The lizardfs command applies to file system objects and allows for example to define the redundancy level for a folder, a file, etc. Example:

lizardfs setgoal -r important_file /mnt/lizardfs/IMPORTANT

On the client side, mounting the storage is as simple as follows:

mfsmount -o big_writes,nosuid,nodev,noatime /mnt/lizardfs

To improve reading performance, a few options can be added:

mfsmount -o big_writes,nosuid,nodev,noatime -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /mnt/lizardfs

Overall use is very simple for a seasoned Linux administrator.

The web interface presents all the reports as tabs, it is possible to display several tabs simultaneously by pressing the small “+”. Here are all the screens (click to enlarge):

screenshot 2 tabs screenshot config modes export+redondance screenshot disks screenshot servers status screenshot master charts screenshot servers charts screenshot global info

Tested configuration

The tested configuration includes 5 “Chunk Servers”. One of them is also a Master, another a Metalogger and a third a Shadow Server. All are cluster clients. A sixth identical machine is also used as a client, either via the FUSE LizardFS module, or via Samba sharing of the LizardFS volume from one of the cluster members.

Each machine includes 16 disks of 8 TB aggregated in Linux software RAID (md-raid) a Xeon D1541 2.1 Ghz 8 cores processor and 16 GB of RAM and is connected to the network with 10 Gigabit ethernet.

The disk performance of the standalone servers was measured beforehand:

16x 8Tb RAID-6

  • writing: 800 MB/s (CPU constrained)
  • reading: 2400 MB/s (1 stream), 1880 MB/s (4 streams)

4 x 8 TB RAID-0

  • writing: 1800 MB/s
  • reading: 2500 MB/s

In order to compare the relative performance of the local RAID-6 and the different redundancy modes of LizardFS, we performed a first test with disks configured as a RAID-6 array on the servers, and without any redundancy at the cluster level. For the following tests, we reconfigured the disks into 4 RAID-0 arrays of 4 disks, in order to maximize local disk performance, while comparing the different redundancy modes:

  • no redundancy: for reference. Obviously not to be used in production!
  • x2 replication : each data block is written to two different chunks. It is a “mirror” mode.
  • XOR 3+1 : a parity block is created for 3 data blocks. Each of the 4 blocks is then written to a different chunk. It’s equivalent to a “RAID-5” array of servers.
  • Erasure Coding 3+2 : two parity blocks are created for 3 data blocks. Each of the 5 blocks is then written to a different chunk. This is equivalent to a “RAID-6”. array of servers.

Tests will focus on sequential performance.

The Tests

Test 1: RAID-0, no redundancy

The purpose of this test is to define maximum performance, limited by network and disk bandwidth. This is our reference point, but of course do not use such a configuration in production, it would be very risky.

Test 1

Test 2: Local RAID-6, no cluster redundancy

This test evaluates the relative efficiency of the distributed parity calculation at the cluster level compared to a local parity calculation on each server. This mode allows the loss of one or two disks per server, but if an entire server failed the cluster would be inoperable.

Test 2

Test 3: RAID-0, replication x2

This mode of replication will undoubtedly be favoured for the most important data. It is the simplest and in our case the fastest, especially in reading. The limiting factor here seems to be the network bandwidth between nodes.

Test 3

Test 4: RAID-0, redundancy XOR 3+1

This redundancy mode allows the failure of a complete chunk (typically a server or RAID volume).

Test 4

Test 5: RAID-0, redundancy Erasure Coding 3+2

This redundancy mode allows two chunks to fail. Although documentation shows optimal performance in this mode, the high processor load limits performance, especially in writing.

Test 5

Test 6: Local RAID-6, no redundancy, SMB sharing

The result of this test is to be compared to test 2. Only one client was used, but accessing the volume through an SMB mount rather than using the LizardFS client. Performance is much lower, but still very satisfactory.

Test 6

Conclusion

The ease of deployment and use of LizardFS makes it a good candidate for very massive storage systems, intended for archiving but also for production. In future tests, we will evaluate the behaviour in case of node failure and cluster extension by adding new systems. It will also be interesting to compare LizardFS to its main competitors.

posté à: 16:08 permalink

The Great Cloud Filesystems Shoot-out : Introduction

Long gone is the time when the professionals with high data storage needs could be satisfied with a simple centralised system like a SAN or NAS. Nowadays, everyone’s thinking about cloud, scalable architectures and capacity, redundancy…

Unfortunately the number of software solutions, platforms, open or proprietary systems available to build these newfangled storage systems is growing rapidly. What are the benefits, the downsides of such and such solution? What are they best used for? Why choose this one over this other one? That’s the reason of this series of tests.

What’s a Cloud Filesystem?

A filesystem is a common way to organise data as files in a hierarchical tree of folders, generally adhering to the POSIX model. Usually the filesystem is hosted in a single storage device, lika an SSD, a hard drive or a RAID array (abstracting away a set of physical drives as a virtual, unified storage volume).

A cluster filesystem allows several different computers (called “nodes”) to access the same filesystem (therefore the same folder tree and files). These cluster filesystems are divided into two families: SAN filesystems and Cloud filesystems (some solutions belong to both categories at the same time).

A SAN filesystem allows a set of systems connected through a storage area network (SAN) to share a common storage device (typically a large SAN-oriented RAID storage array), and to work simultaneously on the same tree of files. Redundancy, scalability are managed by the storage array subsysstem. Some known solutions from this family are Quantum StorNext, HP(SGI) CXFS, IBM GPFS, Tiger tech Tiger Store… In the Free Software/OpenSource world, we have RedHat GPFS, Oracle OCFS… This family of filesystems is not what we’ll be discussing here.

General SAN architecture

A Cloud storage solution gives several computers access to a shared storage volume, but instead of relying upon a shared, distinct storage subsystem, it will instead pool the local storage resources of each cluster member. There are many different cloud storage solutions; some can present their storage as a filesystem, some can’t, but generally offer primarily an “object oriented interface”, particularly targeted towards large internet-based applications, that we won’t treat here. Some have both a filesystem and an object interfaces, but generally in tnat case the object one comes first.

Examples of cloud storage solutions (and their privileged access mode): Scality (object, file connector), Dell/EMC Isilon (file only), OpenIO (object only), CEPH (object, block, file), LizardFS (file), XtreemFS (file), MooseFS (file), RozoFS (file)…

Cloud storage system

A last group of cluster filesystems offer no data redundancy and are tailored for High Performance Computing and Science applications, they’re for instance Lustre, OrangeFS, BeeGFS, etc. These filesystems won’t be detailed here.

Why use a Cloud Filesystem?

Most cloud filesystems have clear benefits in terms of scalability (ability to add more storage as needed without downtime) and redundancy (immunity to the loss of an entire storage node or even a complete datacentre).

We’ll be concentrating in this comparison on filesystems with the following features:

  • ability to add a new node to expand the cluster capacity
  • ability to withstand complete failure of at least one node
  • ability to rebuild data from a failed node

Most of these filesystems work using a user mode (FUSE) driver. The main benefit of FUSE drivers is that they are often also available for MacOS and Windows, therefore giving native access to the storage cluster to client machines running these operating systems instead of going through an additional file-sharing layer. The main downside of FUSE drivers is that they tend to be less robust than native Linux kernel drivers; for instance under very low memory conditions, the driver may be killed by the “OOM killer”. Another limitation is that a FUSE filesystem cannot be shared using the kernel NFS server, which is faster thant the user-mode NFS server.

The Competitors of this Shoot-out

We plan to test the following Cloud Filesystems:

  • LizardFS
  • RozoFS
  • CEPH FS
  • GlusterFS

The goal is to test these in an enterprise storage environment for video production and post-production, archiving, rather than on pure internet-oriented use like massive virtualisation, video streaming, etc.

posté à: 15:35 permalink

Mardi, 22 mai 2018

Le Grand Comparatif des systèmes de fichiers en nuage, Round 1: LizardFS

LizardFS est un système de fichiers en nuage libre développé depuis 2012. Il dérive étroitement de MooseFS, et contrairement à à ce dernier il n’y a pas de fonctionnalités limitées dans la version libre (serveur de métadonnées en haute disponibilité, gestion de redondance avancée).

Architecture

Le système de fichiers est architecturé selon un mode classique. Les différents composants sont:

  • les “Chunk Servers” qui fournissent le stockage proprement dit. Le stockage s’appuie sur un système de fichiers local standard.
  • un “Master Server” qui tient le rôle classique de serveur de métadonnées, qui gère le nommage des objets, l’accès, l’orientation des clients vers le serveur “chunk” contenant les données recherchées.
  • un “Metalogger Server” qui gère une liste des opérations en cours afin de pouvoir reprendre sur incident en cas de coupure brutale du “Master Server”.
  • en option, un ou plusieurs “Shadow Servers” qui sont des serveurs de métadonnées de secours, afin de pouvoir prendre le relai du “Master Server” en cas de problème.
    • et finalement le client FUSE qui permet de monter le système de fichiers localement.

Bien sûr un serveur physique peut assumer simultanément la fonction de “Chunk Server” et de “Master”, “Metalogger” ou “Shadow Server”, ainsi qu’être client.

Schéma LizardFS

Le stockage local va généralement s’appuyer sur des grappes RAID. La redondance au niveau de la grappe de serveur va donc s’ajouter à une éventuelle redondance RAID locale.

La configuration de la grappe est assez simple et décrite dans la documentation LizardFS.

Notez qu’il est très facile de définir des modes de sécurité différents pour différentes parties du système de fichiers global. La granularité s’effectue au niveau du dossier ou même du fichier.

Interface utilisateur

LizardFS s’utilise avec des outils en ligne de commande assez simples, et fournit une interface web commode pour surveiller l’état de la grappe dans tous ses aspects.

L’administration utilise essentiellement les commandes lizardfs et lisardfs-admin pour modifier les paramètres de la grappe.

La commande lizardfs-admin communique avec le Master Server pour modifier les paramètres globaux, par exemple:

lizardfs-admin list-goals  

La commande lizardfs s’applique à des objets du système de fichiers et permet par exemple de définir le niveau de redondance pour un dossier, un fichier, etc. Exemple:

lizardfs setgoal -r important_file /mnt/lizardfs/IMPORTANT

Côté client, le montage se résume à :

mfsmount -o big_writes,nosuid,nodev,noatime /mnt/lizardfs

Pour améliorer les performances en lecture, on pourra ajouter quelques options:

mfsmount -o big_writes,nosuid,nodev,noatime -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /mnt/lizardfs

L’utilisation est globalement très simple pour un administrateur Linux.

L’interface web présente l’ensemble des états sous forme d’onglets, il est possible d’afficher plusieurs onglets simultanément en appuyant sur le petit “+”. Voici l’ensemble des écrans (cliquez pour agrandir):

screenshot 2 tabs screenshot config modes export+redondance screenshot disks screenshot servers status screenshot master charts screenshot servers charts screenshot global info

Configuration testée

La configuration testée comprend 5 “Chunk Servers”. Un d’entre eux est également “Master”, un autre “Metalogger” et un troisième “Shadow Server”. Tous sont clients de la grappe. Une sixième machine identique est également utilisée comme client, soit via le module FUSE LizardFS, soit via un partage Samba du volume LizardFS depuis un des membres de la grappe.

Chaque machine comporte 16 disques de 8 To agrégés en RAID logiciel Linux (md-raid) d’un processeur Xeon D1541 2,1 Ghz 8 cœurs et de 16 Go de RAM et est connectée au réseau en 10 Gigabit ethernet.

La performance disque des serveurs seuls a été mesurée préalablement :

RAID-6 de 16x 8 To

  • écriture : 800 Mo/s (limité par le processeur)
  • lecture : 2400 Mo/s (1 flux), 1880 Mo/s (4 flux)

4 RAID-0 de 4x 8 To

  • écriture : 1800 Mo/s
  • lecture : 2500 Mo/s

Afin de comparer la performance relative du RAID-6 local et des différents mode de redondance de LizardFS, nous avons effectué un premier test avec les disques en RAID-6 sur les serveurs, et sans redondance au niveau de la grappe. Pour les tests suivants, nous avons reconfigurés les disques en 4 grappe RAID-0 de 4 disques, afin de maximiser la performance disque locale, afin de comparer les modes de redondances suivants:

  • aucune redondance : pour référence. Évidemment à ne pas utiliser en production!
  • réplication x2 : chaque bloc de données est répliqué sur deux “chunks” différents. C’est un mode “miroir”.
  • XOR 3+1 : un bloc de parité est créé pour 3 blocs de données. Chacun des 4 blocs est écrit sur un “chunk” différent. C’est équivalent à un “RAID-5 de serveurs”
  • Erasure Coding 3+2 : deux blocs de parité sont créés pour 3 blocs de données. Chacun des 5 blocs est écrit sur un “chunk” différent. C’est équivalent à un “RAID-6 de serveurs”.

Les tests se concentreront sur la performance séquentielle.

Les Tests

Test 1: RAID-0, pas de redondance

Le but de ce test est de définir une performance maximum, limitée par la bande passante réseau et disque. C’est notre point de référence, mais bien entendu n’utilisez pas une telle configuration en production, ce serait très risqué.

Test 1

Test 2: RAID-6 local, pas de redondance de grappe

Ce test permet d’évaluer l’efficacité relative du calcul de parité réparti au niveau de la grappe par rapport à un calcul de parité local sur chaque serveur. Ce mode autorise la perte d’un ou deux disques par serveur, par contre en cas de panne d’un serveur entier la grappe sera inopérante.

Test 2

Test 3: RAID-0, réplication x2

Ce mode de réplication sera sans doute favorisé pour les données les plus importantes. Il est le plus simple et dans notre cas, le plus rapide, surtout en lecture. Le facteur limitant semble être ici la bande passante réseau entre les nœuds.

Test 3

Test 4: RAID-0, redondance XOR 3+1

Ce mode de redondance autorise la panne d’un “chunk” complet (typiquement, un serveur ou un volume RAID).

Test 4

Test 5: RAID-0, redondance Erasure Coding 3+2

Ce mode de redondance autorise la panne de deux “chunks”. Bien que la documentation fasse état d’une performance optimale dans ce mode, la forte charge processeur limite la performance, particulièrement en écriture.

Test 5

Test 6: RAID-6 local, pas de redondance, partage SMB

Le résultat de ce test est à comparer au test 2. Un seul client a été utilisé, mais accédant au volume via un montage SMB plutôt qu’en utilisant le client LizardFS. La performance est nettement inférieure, mais encore très satisfaisante.

Test 6

Conclusion

La facilité de déploiement et d’utilisation de LizardFS en font un bon candidat pour des systèmes de stockage très massifs, destinés à l’archivage mais également à la production. Lors de prochains tests, nous évaluerons le comportement en cas de panne de nœud et d’extension de la grappe par ajout de nouveaux systèmes. Il sera également intéressant de comparer LizardFS à ses principaux concurrents.

posté à: 18:43 permalink

Mercredi, 16 mai 2018

Le Grand Comparatif des systèmes de fichiers en nuage: Introduction

Le temps est révolu où les professionnels aux besoins de stockage importants pouvaient se contenter d’un simple système centralisé de type NAS ou SAN. Désormais, tout le monde pense nuage, architecture scalable, montée en charge, redondance…

Malheureusement il existe un nombre sans cesse croissant de logiciels, de plate-formes, de systèmes ouverts ou propriétaires pour construire ces systèmes de stockage de nouveau style. Quels en sont les points faibles, les points forts, le cadre d’utilisation? Pourquoi choisir un tel plutôt que tel autre? Voilà le but de ce comparatif.

Qu’est ce qu’un système de fichiers en nuage?

Un système de fichiers est une organisation de données selon le modèle bien connu de l’arborescence contenant dossiers et fichiers, généralement suivant le modèle POSIX, avec des variations. Dans le cas général, un système de fichier est contenu dans un seul périphérique de stockage, que ce soit un SSD, un disque dur ou un volume RAID (ce dernier faisant l’abstraction entre un agrégat de disques et un périphérique physique virtuel).

Un système de fichiers en grappe (cluster) permet à plusieurs machines (ou nœuds) d’accéder à un même système de fichier (donc la même arborescence et les mêmes fichiers). Ces systèmes de fichiers en grappe se partagent en deux grands groupes: les systèmes de fichier SAN et les systèmes de fichier en nuage (certains systèmes appartenant aux deux catégories en même temps).

Un système de fichiers SAN permet à un ensemble de machines reliées à un réseau de stockage de partager un périphérique de stockage commun (typiquement, une baie de stockage SAN) et d’y travailler simultanément sur la même arborescence et les mêmes fichiers. La redondance, la scalabilité sont entièrement déléguées au sous-système de stockage SAN. Des exemples de ce type de systèmes sont Quantum StorNext, HP(SGI) CXFS, IBM GPFS, Tiger tech Tiger Store… En logiciel libre nous avons RedHat GPFS, Oracle OCFS… Ce n’est pas notre sujet actuel.

Schéma SAN

Un système de stockage en nuage permet, à plusieurs machines d’accéder à un volume de stockage commun, mais au lieu de passer par un sous-système de stockage partagé, en s’appuyant sur la mise en commun des ressources de stockage individuelles de chaque machine. Il existe un grand nombre de systèmes de stockage en nuage; certains offrent la possibilité de présenter le stockage sous forme de système de fichiers, d’autres non. Ces derniers présentent généralement uniquement une interface “objet”, destinée à des usages Internet de stockage de données massives, et ne seront pas traités ici. Certains sont à la fois objet et système de fichiers, mais privilégient généralement le mode objet.

Exemples de stockage en nuage (et leur mode d’accès): Scality (objet, passerelle fichier), Dell/EMC Isilon (fichier seulement), OpenIO (objet seulement), CEPH (objet, bloc, fichier), LizardFS (fichier), XtreemFS (fichier), MooseFS (fichier), RozoFS (fichier)…

Schéma Nuage

Une dernière catégorie de systèmes de fichiers agrégeant l’espace de plusieurs machines n’offre pas de redondance et sont destinés au calcul intensif et scientifique, ce sont entre autre Lustre, OrangeFS, BeeGFS, etc. Ces systèmes de fichiers ne seront pas traités ici.

Pourquoi un système de fichiers en nuage?

La plupart des systèmes de fichiers en nuage présentent de gros avantages en terme de scalabilité (possibilité d’agrandir le stockage au fil de l’eau) et de redondance.(tolérance à la panne d’un serveur voire d’un centre de données entier).

Tous les systèmes de notre comparatif offrent au moins les capacités suivantes:

  • ajout d’un nœud de stockage à chaud pour étendre la capacité
  • tolérance à la panne d’un nœud de stockage
  • reconstruction d’un nœud de stockage défaillant

La plupart de ces systèmes de fichiers fonctionnent en mode utilisateur (pilote FUSE). L’avantage des pilotes FUSE est qu’ils sont généralement disponibles également pour MacOS et Windows, permettant ainsi aux clients d’accéder directement au système de fichier de façon native. L’inconvénient des pilotes FUSE est qu’ils sont généralement moins robustes que les pilotes natifs intégrés au noyau Linux, en particulier ils sont susceptibles, dans des conditions de charge mémoire importante, d’être arrêtés de force par le “OOM Killer”. De plus, les pilotes FUSE ne permettent pas le partage du système de fichier via le serveur NFS intégré au noyau, qui est plus performant que le serveur NFS en mode utilisateur.

Les concurrents de notre comparatif

Nous avons prévu de tester les systèmes de fichier en nuage suivants:

  • LizardFS
  • RozoFS
  • CEPH FS
  • GlusterFS

L’optique est de tester ces systèmes de fichiers dans un usage entreprise de type stockage de production vidéo, archivage plutôt que pour les usages internet purs type virtualisation massive, diffusion en streaming, etc.

posté à: 17:19 permalink

Lundi, 22 janvier 2018

Nouveautés du format LTO

Les supports et bibliothèques de bandes au format LTO-8 commencent à être disponibles. Le LTO-8 apporte des changements significatifs par rapport aux habitudes qui ont prévalu depuis les origines du format en 2001. Pour la première fois, les règles de compatibilité descendante ont changé.

cartouche LTO

LTO-2 à LTO-7

Du LTO-2 de 2003 jusqu’au LTO-7 de fin 2015, chaque génération de LTO pouvait lire et écrire le format de la génération précédente, et lire deux générations en arrière. Le LTO-7 peut donc lire et écrire les médias LTO-7 et LTO-6, et lire seulement les LTO-5.

Pour rappel, les cartouches LTO-5 ont une capacité native de 1,5 To, les cartouches LTO-6 de 2,5 To, les LTO-7 de 6 To et enfin les LTO-8 12 To.

LTO-8

Le LTO-8 rompt avec cette tradition: en effet si les lecteurs LTO-8 pourront tous lire et écrire les supports LTO-7 et LTO-8, mais ne pourront pas lire les LTO-6.

De plus, les librairies LTO-8 pourront généralement formater les médias LTO-7 en format LTO-8 type M, et ce en fonction du code-barre accolé à ce média: un média LTO-7 vierge dont le code-barre de l’étiquette se termine par “M8” sera formaté en “8 type M”. Sinon, il sera formaté en LTO-7.

Les supports pour le LTO-8 auront donc les capacités suivantes avec un lecteur LTO-8:

MédiaFormatCapacité
LTO-7LTO-7 6 To
LTO-7“M8” 9 To
LTO-8LTO-812 To

Et ensuite?

  • une bande LTO-7 formatée en “M8” ne sera pas lisible sur un lecteur LTO-7.
  • une bande LTO-7 formatée en “M8” ne sera pas, c’est d’ores et déjà connu, lisible par un lecteur LTO-9.
  • de l’information précédente, on peut sans doute anticiper que le LTO-9 ne sera probablement pas compatible non plus avec le LTO-7, mais proposera vraisemblablement un formatage “M9” des médias LTO-8.

posté à: 17:35 permalink

Lundi, 08 janvier 2018

Information sur “Meltdown” et “Spectre”

Deux nouvelles séries de bugs de sécurité très important liés aux processeurs ont été publiés en ce début d’année, “Meltdown” et “Spectre”.

Ces bugs sont matériels, impactent plus ou moins les processeurs Intel, AMD et ARM. Tous les systèmes d’exploitation (Linux, Windows, BSD, MacOS, Android, iOS…), tous les types de matériels (PC, Mac, serveurs, téléphones, tablettes…) sont impactés

Le laboratoire de sécurité de Google a démontré une preuve de concept d’attaque utilisant un code Javascript chargé depuis une page Web ordinaire. Depuis, Mozilla Firefox et Google Chrome ont été mis à jour afin de mitiger ces attaques, assurez-vous d’utiliser un navigateur à jour.

Le site linuxfr.org offre une présentation détaillé et des liens vers de nombreux articles ici.

Systèmes Intellique

La grande majorité des systèmes Intellique actuellement en production sont basés sur des processeurs AMD Opteron. Ils sont donc immunisés contre Meltdown, mais vulnérable à Spectre. Des noyaux corrigés en version 4.4.110 et 4.9.75 sont d’ores et déjà disponibles dans les dépôts intellique, branche unstable.

Dans la mesure où un système n’est pas accessible depuis Internet, le risque d’une attaque est pour l’instant infime. Il n’est donc pas forcément nécessaire de se précipiter pour mettre à jour.

Impact sur les performances

Meltdown semble avoir un impact très important sur les performances des processeurs Intel dans certaines conditions. Les correctifs ralentissent fortement les appels systèmes, ce qui impactera plus fortement les systèmes serveurs que les postes utilisateurs. Chez Epic Games, une augmentation considérable de la charge processeur a été constatée après application des correctifs sur les serveurs applicatifs.

CPU usage at epicgames

source

Spectre pourrait impacter significativement les performances en entrées-sorties, disques et réseau en particulier, sur les serveurs de fichiers. Nous sommes en train de mener des évaluation sur Opteron et Xeon. Les tests préliminaires indiquent que les performances sont peu impactées.

posté à: 18:31 permalink

Vendredi, 01 décembre 2017

Les droits utilisateurs Unix

D’aucuns déplorent la simplicité des droits Unix comparés aux 11 (ou 17) ACLs de NTFS. Pourtant il y a déjà pas mal d’occasions de s’amuser… et de se tirer une balle dans le pied.

La base

Les droits Unix de base sont lecture, écriture, exécution. Ces droits peuvent s’appliquer à trois catégories d’utilisateurs: le propriétaire du fichier, le groupe, enfin tous les autres. Ces différents droits sont encodés sous la forme de 3 valeurs octales, une 4e valeur fournissant les “bits spéciaux”. Ainsi, l’ensemble des droits d’un fichier est commodément stocké dans 12 bits, chaque bit indiquant un des droits. On peut donc appliquer ou lire les droits soit en utilisant leurs noms (les lettres r,w,x,s et t):

$ chmod rwxrxrx fichier

Soit en utilisant directement les valeurs en octal correspondantes aux différentes positions des différents bits:

$ chmod 644 fichier

Exemples

Exécutons les commandes suivantes:

mkdir testdir
ls -ld testdir

Nous obtenons ceci:

drwxr-xr-x 2 storiq users 4096 déc.   1 16:07 testdir/

Ajoutons une explication détaillée:

# droits   nombre d'éléments    propriétaire    groupe  taille  date de modification    nom
drwxr-xr-x      2               storiq          users   4096    déc.   1 16:07          testdir/

Aujourd’hui nous nous intéressons aux droits, à savoir la séquence “drwxr-xr-x” Le “d” au début indique qu’il s’agit d’un dossier (et non d’un fichier ordinaire). Les trois lettres suivantes rwx indiquent les droits du propriétaire, à savoir r pour lecture, w pour écriture, et x pour exécution. Les 3 signes suivants r-x indiquent que les membres du groupe users ont le droit de lecture et d’exécution, mais pas d’écriture. Les trois derniers r-x indiquent les droits pour le reste du monde (hors du propriétaire, des membres du groupe “users”, et bien sûr de l’administrateur “root” qui lui de toute façon fait ce qu’il veut).

Les dossiers sont un peu spéciaux, en ceci qu’ils doivent être porteurs de l’autorisation d’exécution pour pouvoir en lister le contenu. ce qui peut déjà donner de belles occasions de se tirer une balle dans le pied:

$ touch super hyper mega
$ ls -l
total 0
-rw-r--r-- 1 storiq users 0 déc.   1 16:20 hyper
-rw-r--r-- 1 storiq users 0 déc.   1 16:20 mega
-rw-r--r-- 1 storiq users 0 déc.   1 16:20 super
$ chmod -x .
$ ls -l
/bin/ls: impossible d'ouvrir le répertoire '.': Permission non accordée

Ou encore:

$ mkdir testdir
$ chmod 666 testdir # tout le monde peut donc lire et écrire
$ cd testdir
bash: cd: testdir: Permission non accordée

Donc prudence lorsqu’on fait des choses comme chmod -R 666 chemin/… Ce n’est probablement pas ce que vous vouliez faire.

Concernant les fichiers ordinaires (fichiers, programmes…) l’utilisation de chmod est un peu moins risquée, encore que…

# chmod -x /usr/bin/chmod
# chmod 
bash: /usr/bin/chmod: Permission non accordée

Les bits setuid et setgid

‘setuid’ signifie “set user id”, et ‘setgid’ “set group id”.

Le “sticky bit”

Se sortir d’une situation difficile

Si par malheur vous avez rendu non exécutable un programme, par exemple…. ‘chmod’:

$ /lib64/ld-linux-x86-64.so. /usr/bin/chmod
/usr/bin/chmod: missing operand

Si vous avez ajouté un utilisateur à un groupe mais que vous ne souhaitez pas relancer la session, utilisez ‘newgrp’ pour qu’il puisse accéder aux fichiers dont il a besoin.

posté à: 18:34 permalink

Mardi, 10 octobre 2017

Les SSD M.2

Les SSD au format M.2 sont bien commodes: ils sont compacts, rapides, et la plupart des systèmes récents ont le connecteur ad hoc disponible. Cependant il y a quelques pièges à contourner.

(image thessdreview.com)

Il existe deux types de connecteurs femelles (côté carte mère) et deux types de connecteurs mâles (côté SSD). Comme de bien entendu, ce ne sont pas les mêmes, ce serait trop simple! Les cartes mères sont dotées soit d’un connecteur de type B, soit d’un connecteur de type M (le plus courant). Les SSD, eux, sont dotés soit d’un connecteur de type B&M (le plus courant), soit d’un connecteur de type M. Théoriquement il pourrait exister des SSD à connecteur B mais je n’en ai jamais vu.

les connecteurs M2

(image Wikipedia).

Les SSD M.2 peuvent implémenter deux protocoles différents:

  • SATA (pilote AHCI)
  • PCIe (pilote NVMe)

Maintenant, voyons comment tout cela s’ajuste…

Côté carte mère

Si le connecteur est un type M, le mode PCIe est supporté (en 4 voies). Le mode SATA, pas forcément. Si le connecteur est un type B, le mode SATA est supporté. Le mode PCIe sera supporté plutôt en 2 voies.

Côté SSD

Si le connecteur est un type M, le mode PCIe est supporté. Le mode SATA, sans doute pas. Si le connecteur est un type B&M, tout est possible. Certains ne supportent que le SATA, d’autres supportent le SATA et le PCIe en 4 voies, ou en 2 voies.

Problème?

En général, un SSD à connecteur M mâle fonctionnera en PCIe (donc très vite) sur une carte mère à connecteur M femelle.

Par contre, horresco referens, un SSD B&M rentrera dans n’importe quel connecteur, mais peut aussi bien fonctionner à pleine vitesse (NVMe), à vitesse réduite (SATA) ou … pas du tout, si le connecteur de la carte mère est un M supportant uniquement le PCIe et le SSD un modèle supportant uniquement le SATA (cas de la plupart des SSD bas de gamme).

Conclusion…

Si vous voulez être sûr de vous, vérifiez bien les modes supportés par votre carte mère et par le SSD qui vous intéresse. Dans le doute, prenez du connecteur M des deux côtés, c’est plus sûr…

posté à: 17:21 permalink

Mardi, 29 août 2017

CIFS ou SMB?

Un débat terrible agite la toile. Doit-on nommer le protocole de partage de fichiers Windows CIFS ou SMB? Voir par exemple cet article

Windows

Dans l’univers Microsoft, c’est clair: CIFS fait référence à d’anciennes versions telles que celles utilisée par Windows 95, et correspond à l’implémentation par Microsoft du protocole SMB en version 1.0. On ne doit donc plus jamais utiliser CIFS, seulement SMB, de préférence en version 3.0 ou plus.

MacOS

Dans l’univers Apple macOS (anciennement Mac OS X), pas de problème non plus: on peut utiliser depuis le Finder (Command+k) indifféremment les formes cifs://serveur/partage comme smb://serveur/partage; en ligne de commande, on utilisera

mount -t smbfs //serveur/partage /point/de/montage

Commande qui en sous-main, appelera Library/Filesystems/cifs.fs/Contents/Resources/mount_smbfs. Tout cela est logique et cohérent.

Linux

Hélas, dans l’univers Linux, ça se gâte: il y a fort longtemps, on accédait aux partages SMB (CIFS, en général, si vous me suivez bien…) grâce à smbmount qui ne supportait que la version 1.0 du protocole SMB et était fort bogué. smbmount est complètement obsolète depuis au moins 2007 et a été remplacé par… mount.cifs, qui lui implémente le protocole SMB jusqu’en version 3.02 à l’heure où j’écris ces lignes. Non seulement le nom .mount.cifs semble laisser penser que “CIFS est supérieur à SMB”, mais la page de manuel de mount.cifs entretient l’erreur, puisqu’elle indique franchement que CIFS = SMB2 (ce qui est manifestement erroné, on l’a vu plus haut).

Citation de man mount.cifs :

The CIFS protocol is the successor to the SMB protocol and is supported by most Windows servers and many other commercial servers and Network Attached Storage appliances as well as by the popular Open Source server Samba.

La page man fait également plusieurs fois référence au protocole “CIFS/SMB2”.

Du coup, dans l’univers Linux il est courant de penser que CIFS = SMB2 alors que … non.

posté à: 13:51 permalink

Mardi, 16 août 2016

Astuces en bash


Voici quelques petites astuces utiles avec le shell Bash. Faites-en profiter vos amis!

Tout d’abord, il est souvent bien utile de lister uniquement les dossiers. Il suffit de rajouter cette petite fonction dans votre .bashrc:

    function lsd {
        ls -1p $* | grep '/$'
    }

Il vous arrive sûrement d’avoir des problèmes d’édition de ligne, de retour à la ligne ou d’affichage de la ligne courante quand vous redimensionnez votre terminal. Voici quelques commandes qui peuvent vous aider: Tout d’abord, bien sûr, commencez avec

reset

Alternativement, vous pouvez aussi utiliser

shopt -s checkwinsize

Vous pouvez améliorer la situation en définissant cette variable d’environnement (vous pouvez aussi les mettre dans votre .bashrc):

export HISTCONTROL=ignoredups:erasedups

ou

export HISTCONTROL=ignoreboth

Pour éditer les commandes un peu trop longues, il est plus commode de passer par l’éditeur. Si vous avez laissé bash configuré par défaut en mode Emacs, pensez qu’il suffit de faire Ctrl+x Ctrl+e pour ouvrir la ligne en cours dans l’éditeur définit dans $EDITOR.

Si vous voulez éditer la dernière commande entrée, entrez simplement la commande

fc
.

posté à: 17:13 permalink

Lundi, 02 mai 2016

Les disques 10 To “hélium” sont arrivés.

cliquez pour voir la photo

Pour mémoire, les disques rempli d’hélium consomment nettement moins d’énergie que leurs équivalents “air”. Ils sont également plus durables; ils sont d’ailleurs garantis 5 ans, contre 3 pour les “air”.

Pour l’instant, HGST conserve encore l’exclusivité de cette technologie. Les WD “Gold” sont en réalité des HGST rebadgés. Seagate a annoncé l’arrivée de disques hélium, mais on ne les verra pas avant plusieurs mois, au moins.

posté à: 13:44 permalink

Jeudi, 28 janvier 2016

Stockage, Sauvegarde, Archivage


article paru dans le numéro 366 de “la revue des ingénieurs ESME SUDRIA”

Le stockage, la sauvegarde et l’archivage peuvent recourir à tous types de supports: disques durs, bandes, disques optiques, mémoires flash, mais c’est bien l’approche applicative qui définit s’il s’agit de stockage, de sauvegarde ou d’archivage.


Les techniques de protection des données et leurs usages

Il est souvent délicat pour le néophyte de distinguer les domaines d’applications des différentes techniques de stockage et de protection des données, aussi bien les technologies matérielles que logicielles, ou leur mise en oeuvre en un workflow cohérent.

Les architectures des systèmes de stockage tournent autour de trois concepts:

  • les supports : disques durs (intégré au lecteur), bandes magnétiques, disques optiques, mémoires flash.

  • les lecteurs : disques durs, lecteurs de bandes, lecteurs optiques, “disques” SSD. Non détaillés dans cet article.

  • les sous-systèmes matériels : systèmes RAID, bibliothèque de bande, bibliothèque de disques optiques, stockage objet dit cloud.


Les supports de stockage

Disques durs

Le disque dur est sans doute le composant de stockage le plus connu. Il s’agit d’un système d’enregistrement magnétique sur des plateaux (généralement d’aluminium) tournants et accédés par des têtes de lecture/écriture positionnées par un bras oscillant. Contrairement à une légende tenace, les disques durs ne sont jamais sous vide; au contraire, une pression interne minimale est nécessaire à leur bon fonctionnement, la tête de lecture utilisant l’effet venturi afin de conserver une distance optimale à la surface du plateau.

Il existe maintenant des disques durs de 6 et 8 To emplis d’hélium plutôt que d’air. La fluidité de l’hélium réduit les frottements et permet une baisse de la consommation d’énergie d’environ 40%.

Il existe également des disques utilisant la technologie SMR (Shingled Magnetic Recording) dans la quelle les pistes successives se recouvrent légèrement, ce qui permet d’augmenter la capacité (jusqu’à 10 To); par contre il est très difficile de modifier une donnée déjà enregistrée, ces disques sont donc destinés à des applications particulières (stockage à long terme, archivage).

Mémoire flash

La mémoire flash est sans doute le système de stockage de données le plus répandu aujourd’hui, puisqu’il est présent dans les centaines de millions de téléphones mobiles et de plus en plus d’ordinateurs portables. La mémoire flash ne présentant pas de parties mobiles contrairement aux disques durs, elle est insensible aux chocs, tout en présentant d’excellentes performances. Ses principaux inconvénients sont son rapport capacité/prix défavorable, et sa résistance à l’usure (on ne peut récrire une “cellule” qu’un nombre limité de fois).

La mémoire flash est donc rarement utilisée dans des systèmes de stockage massif, sinon comme cache rapide pour un ensemble basé sur des disques magnétiques.

Bandes magnétiques

Et oui, la bande magnétique résiste encore et toujours. Les grands constructeurs IBM, HP et Quantum ont défini à la fin des années 90 un standard commun dit LTO (Linear Tape Open) qui aujourd’hui à la 6e génération (2,5 To natifs par cartouche), est le format de très loin le plus répandu. La bande magnétique présente des caractéristiques intéressantes: le support est peu cher comparé aux disques magnétiques, il est conçu pour se conserver très longtemps (les supports LTO sont garantis 10 ans sous certaines conditions) et il consomme peu d’énergie. Si le LTO présente une performance intéressante (environ 150 Mo/s pour le LTO 6), bien entendu le principal inconvénient reste l’accès séquentiel aux données enregistrées qui peut entraîner des temps d’accès très élevés (plusieurs dizaines de secondes).

disques optiques

Les disques optiques sont aujourd’hui en perte de vitesse du fait de leur faible capacité et leur faible vitesse. Sony cependant propose actuellement un format ODA (Optical Disc Archive) qui présente des capacités jusqu’à 1 To par cartouche. Le principal attrait du disque optique réside dans sa longévité: l’ODA est donné pour pouvant se conserver 50 ans. La vitesse de lecture et d’écriture, par contre, reste limitée, aux environs de 40 à 50 Mo/s.

Pour plus de considérations sur les supports de stockage, et en particulier des détails techniques sur les disques magnétiques et SSD, voir http://fr.slideshare.net/eflorac/prsentation-stockage


Sous-systèmes

Système RAID

un assemblage RAID (Redundant Array of Inexpensive Drives) est un assemblage logique de disques durs ou de SSD résistant à la panne. Le fait de regrouper logiquement un ensemble d’éléments augmente bien entendu la probabilité de panne, pour s’en protéger le système RAID soit duplique les données (RAID 1, RAID 10) soit calcule des données de parité permettant de reconstituer une donnée qui viendrait à manquer (RAID 5,6) à partir des données restantes.

Les modes de RAID les plus couramment utilisés sont le RAID 1 ou 10 (miroir) et le RAID 6. Il convient de considérer le RAID 5 comme obsolète pour les capacités des disques durs actuels. Voir http://blogs.intellique.com/tech/2012/10/31#Raid5-est-mort

L’utilisation du RAID présente donc les avantages suivants: - augmentation de la capacité : il n’existe pas de disques durs de 24 To, mais le RAID permet d’assembler par exemple 8 disques de 4 To et de les présenter comme un seul volume de 24 To utiles. - augmentation de la performance : l’assemblage de 8 x 4 To donné en exemple sera environ 6 fois plus performant qu’un seul disque de 4 To. - continuité de service : en cas de défaillance d’un disque, le remplacement de celui-ci se fait sans interruption.

L’utilisation du RAID ne protège pas contre la malveillance, les erreurs humaines, ou les incidents de plus grande ampleur; s’il y a un incendie dans la salle serveur, ou une inondation, le RAID ne permettra ni de garantir la continuité de service, ni la reprise d’activité. L’utilisation du RAID ne constitue donc pas une stratégie de sauvegarde, ni d’archivage.

Pour plus de détails sur les différents modes de RAID, voir http://fr.slideshare.net/eflorac/prsentation-du-stockage-raid

Bibliothèque de bandes ou disques optiques

Une bibliothèque de bande ou de supports optiques est un système contenant un certain nombre de supports (allant de 8 à plusieurs milliers), un certains nombre de lecteurs pour ces supports et un bras robotisé permettant de charger et décharger les supports dans les lecteurs à la demande.

Les bibliothèques de ce type présentent l’avantage de contenir une masse de données très importantes accessible de manière entièrement automatisée. De plus, ces systèmes consomment très peu d’énergie.

L’inconvénient principal réside dans le temps d’accès important (typiquement quelques minutes) et l’adressage indirect, qui implique en général une couche logicielle de gestion sophistiquée.

stockage objet dit Cloud

La volumétrie des données croissant sans cesse et leur mode d’utilisation évoluant, de nouvelles approches sont apparues pour la gestion de stockage extrêmement massif. Les systèmes de type “stockage objet” tel que Ceph, Gluster, Scality… visent à assurer la disponibilité des données par la réplication, en suivant un mode de découpage et de répartition des données qui permet de supporter non seulement la panne d’un composant (tel un disque dur) mais aussi d’un sous-système arbitrairement grand (un serveur de stockage, une baie de serveurs, voire un centre de données). L’avantage principal de ces systèmes est de permettre d’accroître l’espace de stockage par ajout de nouveaux sous-systèmes, et de réformer les éléments obsolètes simplement, sans jamais nécessiter de migration globale des données.

Ces nouveaux systèmes ne sont intéressants en terme d’investissement qu’au delà de 1 Po de données, mais ils se démocratisent rapidement.


Applications logicielles

Différentes catégories d’applications de gestion du stockage

virtualisation de stockage

Les applications de virtualisation de stockage permettent de présenter aux utilisateurs ou aux applications des volumes de stockage virtuels décorrélés de l’organisation physique des systèmes de stockage. Elles permettent également fréquemment de déplacer les données utilisées le plus fréquemment vers les systèmes de stockage les plus performants, et les données peu utilisées vers des systèmes moins coûteux voire “dormants” (sur bande). Historiquement les premiers systèmes de ce type ont été les HSM (Hierarchical Storage Manager) qui permettent d’utiliser une bibliothèque de bande comme extension transparente d’un système de stockage sur disque: les fichiers peu utilisés sont stockés sur bande, et chargés à la demande, le début du fichier étant conservé sur disque.

clichés

Les clichés (ou snapshots) sont un mécanisme généralement intégré aux systèmes de fichiers (Oracle ZFS, NetApp WAFL…) ou aux gestionnaires de volume (Symantec VxVM, Linux LVM…). Ce mécanisme permet de “figer” l’état du volume ou du système de fichier à un instant donné. Ainsi, les fichiers effacés après la prise du “cliché” restent présents dans celui-ci. Ce système est fréquemment employé comme premier niveau de sauvegarde de données.

gestionnaire de versions

Les gestionnaires de version sont une gamme d’outils permettant de conserver les versions successives d’un ensemble de fichiers après chaque modification. Généralement l’enregistrement est explicite via une commande dite de commit ou check-in.La plupart des gestionnaires de versions sont utilisés dans un environnement de développement logiciel coopératif, afin de permettre aux différents développeurs de partager leurs modifications successives de code.

  • Les systèmes historiques : RCS, CVS
  • Les systèmes propriétaires: Perforce, Microsoft SourceSafe
  • Le système libre dominant jusqu’à récemment: Subversion (svn)
  • Les systèmes distribués: git (Linux), Mercurial, Bazaar.

Sauvegarde

La sauvegarde vise à protéger les données de deux aspects non couverts par la simple redondance matérielle, à savoir les erreurs humaines (“oups, je n’aurai pas du faire ça”) et les accidents de plus grande ampleur comme les incendies, inondations, etc. afin de maintenir idéalement la continuité de service, ou à défaut une reprise d’activité aussi rapide que possible.

Pourquoi sauvegarder? Parce que les données sont absolument critiques dans toute entreprise! Une étude Infocorp de 2002 indique que 30% des entreprises subissant une perte de données faisaient faillite.

Une bonne sauvegarde trouve la péréquation entre coût et risque afin de se protéger suffisamment. Elle suppose en général 1° une copie complète des données faite aussi souvent que possible 2° un historique suffisant pour pouvoir revenir en arrière en cas de problème non immédiatemment détecté 3° au moins une copie distante, en cas de problème grave sur le site de production.

Les applications et systèmes de sauvegarde sont innombrables, aussi bien sous forme de matériel, de logiciel que de services “cloud”. Quoi qu’il en soit:faites des sauvegardes!

Archivage

Distinction entre la sauvegarde et l’archivage

La sauvegarde est destinée à protéger les données indispensables à la production; elle sécurise les données selon différentes stratégies mais ne prétend pas garantire la disponibilité à long terme des données, typiquement au delà d’un an. L’archivage propose au contraire de garantir la disponibilité des données sur le long terme.

On distingue deux approches: l’archivage patrimonial visant à conserver l’information sur une durée illimitée ( Ce qui implique non seulement de protéger la donnée, mais également les éléments nécessaires à son exploitation ou son interprétation, y compris parfois les éléments matériels ). L’archivage à valeur probante destiné à garantir l’intégrité et l’authenticité des données, généralement sur une durée définie de façon réglementaire et rarement supérieure à 10 ans (factures, contrats, etc). C’est ce que recouvrent les solutions dites “coffre-fort électronique”.

posté à: 18:09 permalink

Lundi, 09 novembre 2015

Restaurer une table de partition GPT corrompue avec parted

Admettons que (suite à une coupure de courant, un bloc de disque dur défectueux, une erreur de manipulation ou autre) que votre système ne démarre pas, parce que la table de partition est corrompue. Le problème peut se manifester de plusieurs façons, par exemple le chargeur de démarrage GRUB reste coincé sur “Loading GRUB stage 1.5”, ou bien parfois le chargeur de démarrage parvient à charger le noyau, mais celui-ci s’arrête avec “No root found”, puis vous lâche dans le Busybox de l’initrd; après quoi la commande cat /proc/partitions renvoie quelque chose comme:

major minor  #blocks  name

   8       16  488386584 sda

Dépité, vous démarrez sur un système de secours et vous lancez parted sur votre disque:

parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
OK/Cancel? OK                                                             
Model: ATA ST3500630AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size     File system     Name     Flags
 1      1049kB  24,7GB  24,7GB   ext4            root
 2      24,7GB  25,8GB  1096MB   linux-swap(v1)
 5      24,7GB  500GB  1096MB    xfs

(parted)                                                                  

Vous voyez bien que parted utilise la copie de secours de la table de partition, mais vous avez beau chercher dans la documentation, aucune commande ne permet de réécrire cette table! Heureusement, la solution est simple: il faut modifier la table de partition. Pour cela il suffit de créer une partition bidon, qui commence et qui finit au même bloc, le dernier, comme ceci:

(parted) mkpart                                                           
Partition name?  []? test
File system type?  [ext2]?                                                
Start? -1                                                                 
End? -1                                                                   

On vérifie le résultat:

(parted) print                                                               
Model: ATA ST3500630AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size     File system     Name     Flags
 1      1049kB  24,7GB  24,7GB   ext4            root
 2      24,7GB  25,8GB  1096MB   linux-swap(v1)
 5      24,7GB  500GB  1096MB    xfs
 3      500GB   500GB  49,2kB    ext2            test
 
Au passage, remarquez qu’il n’y a plus de message d’erreur… Maintenant supprimons la partition inutile ( attention, interdiction de se tromper! ):
(parted) rm 3                                                             
(parted) q                                                                
Information: You may need to update /etc/fstab.

Et voilà, sauvé!

posté à: 13:50 permalink

Mardi, 26 mai 2015

L’état du stockage dans le Cloud

Nasuni Corp. a publié le résultat de son rapport sur l’état du stockage Cloud, qui teste la vitesse de lecture, d’écriture et de suppression, la disponibilité et la montée en charge des trois grands acteurs du stockage Cloud public, à savoir Amazon, Google et Microsoft. Voici le lien vers le rapport complet.

Ce qui nous intéresse le plus dans ce rapport, ce sont certains chiffres de cette infographie (cliquez sur l’image pour l’infographie complète): cliquez pour l'infographie complète

Que note-t-on? Les performances maximales des services de fichiers basés sur le Cloud public sont au moins 100 fois inférieures à un NAS professionnel tels les StorIQ d’Intellique. Les débits ne sont même pas équivalents à un disque USB grand public; les temps de réponses, eux, sont … très longs.

Pour un usage très modéré, strictement bureautique, cela pourra convenir à la rigueur (si on est prêt à travailler avec une performance très inférieure à celle du disque local de son PC); pour tout usage même modérément intensif, c’est encore clairement très insuffisant.

Le Cloud public reste donc une solution d’appoint, d’archivage ou de sauvegarde, mais certainement pas de production.

posté à: 13:31 permalink

Lundi, 30 mars 2015

Les disques 8 To sont là!

cliquez pour voir la photo

C’est un HGST He8. Il est rempli d’hélium comme son petit frère de 6 To.

Sa consommation électrique est très faible comparée au 6 To HDS “air”: 7,5W contre 11,5W en pointe. Il est également plus léger. Les tests de performance vont commencer, mais il est d’ores et déjà disponible.

posté à: 17:51 permalink

Vendredi, 24 octobre 2014

Les commandes utiles: wipefs, lsblk et blkid


Voilà une nouvelle rubrique, “les commandes utiles du jour”, pour tous ceux qui travaillent sous Linux avec des disques durs. Aujourd’hui, wipefs, lsblk et blkid.

Qui n’a pas eu à recycler un disque dur et voudrait savoir ce qu’il y a dedans avant de l’effacer? Qui n’a jamais voulu recycler un disque, mais ne pas être embêté par les messages d’erreur de LVM par exemple (qui va automatiquement verrouiller un disque comportant des signatures LVM)?

Les outils du jour vont nous aider:

  • blkid : permet de savoir ce qu’il y a sur un disque, une partition.
  • wipefs : permet de supprimer les signatures RAID, LVM, ou de systèmes de fichiers, ou encore les tables de partition sur un disque, une partition, ou un périphérique bloc quelconque (qui a dit disquette?)
    • lsblk : affiche une jolie arborescence des périphériques, bien pratique quand on a des disques découpés en partitions, elles-mêmes assemblées en RAID, le tout découpé en volumes logiques LVM!

Bien entendu il vous sera facile de trouver plus d’information dans les pages man de chacun de ces outils, qui font partie du paquet util-linux sous la plupart des distributions et sont généralement installés par défaut.

Bonus: file -s /dev/ : la commande file -s sur un périphérique bloc donne des informations recoupant celles fournies par blkid mais pas seulement. Utilisez les deux :)

posté à: 12:32 permalink

Jeudi, 22 mai 2014

Terminologie des SSD


Les SSD se sont généralisés bien sûr dans les ordinateurs portables, mais aussi dans le monde de l’entreprise où leur vitesse pure les rend indispensables aux applications transactionnelles, aux bases de données, etc. Afin de vous aider à faire le tri, voici donc une rapide présentation des technologies présentes dans les SSD.

Endurance des SSD

La mémoire flash ne permet qu’un nombre limité d’écritures par emplacement. Le nombre d’écritures possible dépend de la technologie flash utilisée, MLC ,eMLC ou SLC (voir ci-dessous).

DWPD ( diskful writes per day )

L’acronyme DWPD est un méthode d’évaluation de l’endurance des SSD qui évalue le nombre d’écritures complètes que supporte un SSD sur sa durée garantie d’utilisation (généralement 5 ans). Un SSD garanti 5 ans avec un DWPD de 10 peut donc être écrit entièrement 10 fois par jour pendant 5 ans.

MLC

La mémoire MLC (Multi Level Cell) stocke plusieurs bits par cellule, typiquement 2 (il existe des types de cellules stockant 3 ou 4 bits mais en général ils sont réservés aux clefs USB bas de gamme et autres stockages peu sollicités). C’est le type de mémoire flash le moins coûteux et le plus capacitif, mais sa durabilité est limitée à cent ou deux cent mille écritures environ.

eMLC

La mémoire eMLC (“enterprise MLC” ou “enhanced MLC”) est une variante de MLC un peu plus performante et fiable que le MLC (en général donnée pour 500 000 à 1 million d’écritures).

SLC

La mémoire SLC (Single Level Cell) ne stocke qu’un seul bit par cellule. Elle est donc environ deux fois moins dense que la MLC, mais en contrepartie est 10 fois plus durable (1 à 2 millions d’écritures). Le coût de la SLC est environ 3 à 4 fois supérieur au MLC à capacité équivalente.

déduplication

La plupart des contrôleurs SSD intègrent des fonctions de déduplication afin de limiter les écritures. Ceci a pour effet de fausser les mesures de performances lorsqu’on utilise soit un motif répétitif (sujet à une forte déduplication donc des performances anormalement élevées), soit au contraire un motif aléatoire (impossible à dédupliquer, donc donnant des performances anormalement basses).

Ramasse-miettes

Les mémoires flash s’écrivent par unités appelées pages d’une taille typiquement de 4 Ko, mais s’effacent par blocs typiquement de 128 ko à 2 Mo (ou plus). Afin d’améliorer la performance et de limiter l’usure de la flash, lors de la modification d’une page elle est en fait réallouée et récrite sur un emplacement libre, et la donnée antérieure marquée comme “périmée”. Un processus de “ramasse-miettes” peut être initié automatiquement ou volontairement pour effacer les blocs de données périmées et ainsi libérer de l’espace pour les prochaines écritures, de préférence à un moment où cette activité impactera le moins possible la production.

répartition de l’usure ( wear leveling )

Le contrôleur du SSD tient le compte du nombre de cycles d’effacement pour chaque bloc, de façon à répartir au mieux les données afin que tous les blocs aient un taux d’usure similaire. En effet, certains types de fichiers (fichier de pagination, base de données…) peuvent être modifiés très fréquemment toujours aux mêmes emplacements. Sans réallocation dynamique des blocs, les pages hébergeant ces fichiers atteindraient très rapidement leur limite d’usure entrainant la panne du SSD.

surallocation ( over provisioning )

Afin d’améliorer la fiabilité, chaque SSD comporte un surplus de mémoire flash non exploitable, utilisée pour répartir l’usure et prolonger le nombre total d’écritures possibles. La différence principale entre un SSD MLC et eMLC porte sur cette réserve: chez un même constructeur on trouvera généralement deux modèles comportant une capacité de mémoire flash physique équivalente (par exemple 512 Go de flash) mais la capacité disponible variera, de 400 Go pour la version eMLC à 460 ou 480 Go pour la version MLC.

Notons qu’il est parfaitement possible (et même recommandé) d’augmenter encore la durabilité d’un SSD en le partitionnant de manière à ne jamais utiliser une certaine proportion de son espace libre. Pour les applications intensives en écriture, nous conseillons de conserver 20% de la capacité inutilisée.

amplification des écritures ( write amplification )

Il peut arriver que le nombre d’écriture tel que reporté par le système d’exploitation donne lieu au niveau de la flash à un nombre d’écritures bien plus grand. Le cas le plus courant sera celui où le SSD étant utilisé près de sa capacité maximale, n’aura plus de blocs libres pour allouer de nouvelles pages et sera contraint d’effectuer des cycles de lecture/effacement/écriture de blocs entiers. Là encore, la solution consiste à conserver une bonne marge de capacité inutilisée sur le SSD.

protection de l’alimentation par condensateurs

Les SSD eMLC et SLC destiné aux usages professionnels comportent des condensateurs de forte capacité qui permettent, en cas de coupure intempestive de l’alimentation, de fournir suffisamment d’énergie pour terminer les écritures en cours et ainsi éviter une corruption de données.

PCIe vs SAS vs SATA

Les SSD sont disponibles sous différents formats (nous ne considérons pas les modules pour ordinateurs portables): SATA, SAS et PCIe.

  • Les SSD à interface SATA sont les moins coûteux. Cependant, le SATA 3 ne permet qu’une vitesse de 6 Gbits/s, soit environ 700 Mo/s, ce qui est tout juste suffisant pour les modèles les plus performants.

  • Les SSD à interface SAS 12 Gbits/s sont sensiblement plus coûteux, et sont généralement des modèles à base de SLC, beaucoup plus performants que les modèles SATA. On trouve des SSD SLC SAS pouvant fournir jusqu’à 120.000 IOPS (entrées-sorties par seconde) et plus.

  • Les SSD à interface PCIe se présentent sous la forme de cartes PCIe. L’inconvénient de ce format est qu’il est impossible de remplacer un SSD défectueux sans interruption de service. Cependant l’interface PCI Express fournit une bande passante très élevée (plusieurs gigaoctets par seconde) et surtout des temps de réponse très faibles de l’ordre de 50 à 200 nanosecondes (contre 50 à 100 microsecondes pour le SAS). Les SSD sur PCIe présentent des performances de 100.000 à 10.000.000 d’IOPS environ.

posté à: 18:20 permalink

Vendredi, 28 mars 2014

Le premier disque 6 To est arrivé!

cliquez pour voir la photo

C’est un HGST He6. Il est rempli d’hélium, du coup il est scellé (absence de vis) contrairement aux disques durs ordinaires.

Le premier test rapide indique une grande vitesse en accès séquentiel: 228 Mo/s en lecture, 183 Mo/s en écriture.

Sa consommation électrique est très faible comparée au 4 To “air”: 7,5W contre 11,5W en pointe. Il est également plus léger.

En terme de prix, il coûte environ 15% plus cher au To que le 4 To. Mais il faut considérer les gains en place, en consommation électrique, et en fiabilité. Bien qu’annoncé avec le même MTBF que le 4 To ( 2 millions d’heures), HGST est confiant sur sa capacité à faire mieux.

En fin d’année on devrait voir arriver le 6 To “air” et le 8 To “hélium”.

posté à: 15:14 permalink

Mardi, 05 novembre 2013

Comprendre la charge système sous Linux (et Unix)

Administrateurs système, vous connaissez sans doute ces chiffres mystérieux qui apparaissent dans la sortie des commandes top, procinfo, uptime, w et tant d’autres, par exemple:

    [~]$ uptime 
     15:08:24 up 5 days,  4:17,  2 users,  load average: 0.08, 0.24, 0.29

Mais à quoi sert donc cette mystérieuse “load average”, charge système? Et pourquoi trois valeurs?

Une, cinq et quinze minutes

Les trois valeurs correspondent à la charge système moyenne sur les 1, 5 et 15 dernières minutes, telle que mesurée par le noyau. Notons au passage que les chiffres sont dans l’ordre inverse par rapport au temps… Si on veut déterminer la tendance, il faut donc considérer les chiffres à l’envers: dans l’exemple ci-dessus, la charge décroît au fil du temps, de droite à gauche.

Processeur, entrées-sorties, interruptions

Ceci ne nous dit pas ce qu’est la charge système. Elle est une mesure du nombre de processus actifs sur le système, et ajoute le nombre de processus en attente; l’unité 1.00 représente l’utilisation à 100% d’un processeur (ou coeur).

Du fait de cette double mesure, la charge système évolue en fonction à la fois de la charge du processeur, des entrées-sorties et des interruptions matérielles.

Si on ne considère que la charge processeur, un processeur utilisé à 100% pendant une minute se traduira par une charge de 1 pour la dernière minute (sous Linux; sous Solaris, la valeur est divisée par le nombre de processeurs ou coeurs); hors de toute autre activité, on aura donc une charge de 0.20 sur les 5 dernières minutes, et de 0.06 sur le dernier quart d’heure.

Charge et réactivité

Le lien entre la charge système et la réactivité du système est indirect: selon le type de système d’exploitation, une charge processeur maximale, produite par exemple par un calcul en arrière-plan, peut ne pas induire de ralentissement sensible pour les autres processus; a contrario, une charge système élevée induite par des processus nombreux en attente d’entrées-sorties (par exemple de très nombreux clients NFS accédant à de multiples fichiers) peut provoquer l’apparition de temps de réponses très importants.

Utiliser la charge

On considère généralement une valeur “élevée” si elle est très supérieure au nombre de processeurs; ce qui reste subjectif, une machine pouvant fonctionner normalement avec une charge système de 100 ou plus : la commande cat /dev/zero > /dev/null chargera un processeur à 100%, mais n’aura pas d’impact sur la réactivité parce qu’aucune ressource limitée n’est en jeu.

La charge système est un signal d’alarme; apprenez à connaître les plages de charge normale pour votre système, et recherchez les problèmes en cas de dérive importante.

posté à: 15:41 permalink

Lundi, 07 janvier 2013

Évolution des disques SATA

Nous avons récemment effectué un test comparatif entre disques SATA-3 2 To de dernière génération et disques SAS 73 Go 15000t/mn de 2007. Pourquoi cela? afin d’évaluer la performance relative des disques haut de gamme d’il y a 5 ans avec les disques “classiques” actuels (que de nombreux constructeurs confinent à la catégorie “near line”).

La configuration matérielle et logicielle testée est en tout point identiques, seuls les disques ont été changés. La configuration testée est la suivante:

processeurAMD Opteron 6128 8 coeurs
mémoire16 Go DDR3 1333 ECC Kingston
carte mèreSupermicro H8SGL
contrôleur RAIDAdaptec 7805Q
configuration RAID 7 disques en RAID-6, bande de 256 Ko + 1 hot spare
Système d’exploitationStorIQ 3.5.3 (base Debian 6.0.6)
Noyau3.2.36-storiq64-opteron #1 SMP Thu Jan 3 19:10:41 CET 2013 x86_64 GNU/Linux

Les six tests suivants ont été effectués avec Bonnie++: écriture séquentielle de 32 Go, lecture et écriture simultanée de 32 Go, lecture de 32 Go; nombre positionnements aléatoires par seconde (“random seek”); nombre de créations de fichiers par seconde (divisé par 100 pour l’échelle); nombre de suppressions de fichiers par seconde (divisé par 100 pour l’échelle).

Voici les résultats chiffrés et le graphe:

DisquesÉcriture Mo/sécriture/lectureLecture Mo/spos./sec100 créa./seconde100 suppr./sec.
SAS 73 Go424,43209,35531,71893,70281,12385,30
SATA 2 To655,35306,75713,13627,05325,76386,21

graph

On voit clairement que les disques SATA actuels font largement mieux que les disques SAS d’il y a 5 ans sur tous les tests sauf un, le positionnement aléatoire. Pensez-y lors du renouvellement de vos systèmes de stockage: un système SATA actuel peut venir remplacer un ancien système SAS dans la plupart des cas d’utilisation.

posté à: 15:45 permalink

Jeudi, 22 novembre 2012

Petit guide de paramétrage de NFS

Afin d’optimiser les performances de votre serveur NAS StorIQ voici un petit guide d’optimisation des partages NFS.

Nombre de démons nfsd en attente

Le premier point à vérifier est le nombre de démons nfsd en attente de connexion défini dans le fichier /etc/defaults/nfs-kernel-server:

  # Number of servers to start up
  RPCNFSDCOUNT=8

. Dans l’idéal on aura à peu près autant de démons que de clients simultanés, de préférence dans une limite raisonnable autour de 4 démons par coeur de processeur (soit 16 à 64 en général).

Paramètres des ports

Le règle de base: si vous ne savez pas trop à quoi ça sert, n’y touchez pas. Les réglages par défaut sont bons: vous pourrez toujours saturer très aisément un lien gigabit ( environ 110 à 120 Mo/s utiles). Laissez donc les rsize, wsize tranquilles! La plupart des guides les mentionnant sur le net sont antédiluviens, et s’appliquent uniquement si vous avez un réseau 10 BaseT, et que votre serveur est une SparcStation 20.

Par contre, un problème classique se pose avec les systèmes BSD, donc Mac OS X: ils utilisent les ports réservés (inférieurs à 1024). Votre export doit donc avoir le paramètre “insecure” pour pouvoir fonctionner avec un Mac!

Paramètres des écritures

Oui, le mode synchrone est plus sûr. Cependant le risque d’utiliser le mode asynchrone reste raisonnable au vu de la fiabilité générale des systèmes actuels, et peut donner un gain significatif en performance. Particulièrement si on utilise un contrôleur RAID avec cache et batterie.

Paramétrage réseau

L’utilisation de “jumbo frame” ne fait plus guère de différence sur le matériel actuel sauf sur du réseau InfiniBand. Si vous utilisez du Gigabit Ethernet, il n’y a rien à gagner: vous devez aisément saturer un port à 110 ou 120 Mo/s en NFS3 comme en NFS4.

Par contre, l’utilisation du bonding est intéressante et souvent oubliée. Si vous voulez en savoir plus sur le bonding, je vous conseille la lecture de la page de manuel de l’outil StorIQ “bonding_cli”.

N’oubliez pas que quel que soit le mode d’agrégation des liens, une connexion IP transitera toujours par un seul câble physique. Si vous avez besoin de plus de débit entre deux machines seulement, le 10 Gigabit Ethernet s’impose, et n’est plus très cher.

Paramétrage des disques

La partie probablement la plus méconnue et la plus souvent oubliée. Il faut savoir que les réglages par défaut des systèmes linux sont curieusement optimisés plus pour des systèmes bureautiques que des serveurs, et ce alors qu’il y a sans doute plus de serveurs Linux que de postes clients.

Les différents éléments à passer en revue sont les suivants : l’ordonnanceur (IO scheduler), les files d’attente de disques, l’antélecture de disque.

Depuis quelques années l’ordonnanceur par défaut des systèmes Linux est “cfq” “Completely Fair Scheduler”. Il est plutôt efficace quand vous n’avez qu’un seul disque dur; par contre, si votre serveur utilise un contrôleur RAID matériel, celui-ci embarque son propre ordonnanceur qui sera toujours plus efficace car au fait de la configuration matérielle. Donc si vous utilisez un contrôleur RAID de quelque type que ce soit, configurez votre ordonnanceur comme “noop”. Il y a plusieurs manières de procéder dépendant des distributions; on peut le configurer lors de la compilation du noyau, sur la ligne de commande du chargeur de démarrage (GRUB ou LILO), ou en cours d’éxécution:

echo noop > /sys/block/sda/queue/scheduler

De même, la file d’attende disque par défaut convient pour un disque simple, mais pas du tout pour une grappe RAID doté d’un cache significatif. On peut également l’augmenter sensiblement. La valeur la plus adaptée dépend bien sûr du modèle de contrôleur, type de grappe RAID, etc:

echo 512 > /sys/block/sda/queue/nr_requests 

L’antélecture de disque (“readahead”) est également essentielle. La valeur par défaut du noyau Linux est probablement optimisée pour un disque IDE de 8 Go: 128 Ko. Il existe deux façons de le modifier, soit via la commande “blockdev”, soit comme précédemment via le pseudo-filesystem /sys:

echo 16384 > /sys/block/sda/queue/read_ahead_kb 

Là encore, il faudra expérimenter différentes valeurs pour obtenir la meilleure performance. Sur un serveur doté d’une grappe RAID assez grande, une valeur minimale se calcule en fonction de la largeur de bande de la grappe et du nombre de disques de données. Par exemple, une grappe RAID-6 de 12 disques comporte 10 disques de données et une largeur de bande de 64 Ko; la valeur minimale d’antélecture doit être 640 Ko. En pratique sur une machine rapide, on obtiendra une performance optimale en lecture séquentielle avec des valeurs beaucoup plus grandes (plusieurs mégaoctets).

Pour finir, le choix du système de fichier: la situation est heureusement assez simple. À mon sens, un seul système de fichier convient pour les volumes de grande taille, et c’est xfs.

Si vous partez d’une installation par défaut d’une distribution courante avec un volume partagé en ext3 et que vous appliquez tous ces conseils, vous pourrez aisément augmenter les performances de 100 à 500%.

posté à: 19:33 permalink

Mercredi, 31 octobre 2012

Rappel : la mort du RAID-5

Il est arrivé encore récemment qu’on me parle du RAID-5 comme si c’était toujours une technologie d’actualité. Du coup, je me sens obligé de faire un petit rappel à caractère sanitaire : le RAID-5 est mort depuis déjà quelques années, et n’est généralement pas le bon choix pour protéger ses données.

L’évolution de la capacité des disques durs est le principal facteur: la capacité des disques double globalement tous les 18 à 24 mois, alors que la vitesse augmente de quelques pourcents sur la même période. Résultat: le remplissage d’un disque dur prend de plus en plus de temps.

Premier problème: lorsqu’un disque tombe en panne, la grappe RAID reste non protégée de plus en plus longtemps, à savoir le temps nécessaire pour emplir un disque entier:

  • en 1988, un disque de 40 Mo se remplissait en 2 à 3 minutes
  • en 1998, un disque de 9 Go se remplissait en 15 à 20 minutes
  • en 2008, un disque de 1 To se remplissait en 3 à 4 heures
  • en 2010, un disque de 2 To se remplit en 5 à 6 heures
  • En 2012, un disque de 4 To se remplit en 12 à 14 heures

Il s’agit là d’une performance maximale; il est normal que la performance réelle constatée soit beaucoup plus basse, surtout lorsque la grappe RAID est sollicitée pendant la reconstruction; il n’est pas anormal qu’une reconstruction se prolonge un ou deux jours, voire plus. Déjà, il faut avoir les nerfs solides, mais ce n’est pas le pire…

Ensuite les statistiques jouent contre nous : les disques durs courants présentent un taux d’erreur non correctible d’environ 1 bit pour 1E14 (mesuré par nous) à 1E15 (donné par les constructeurs). Ça paraît au premier abord beaucoup, mais en fait ça n’est pas tant que ça si on se rappelle que les disques durs actuels sont vraiment énormes et contiennent jusqu’à 3,2E13 bits (disque de 4 To). De plus, quand on additionne les disques dans une grappe RAID, on additionne les capacités mais aussi les erreurs.

Une grappe de 10 disques de 4 To contient environ 3,2E14 bits. Lors de la reconstruction d’un disque, on rencontrera (si le taux d’erreur réel est de 1 sur 1E14) 3,2 erreurs de façon statistiquement certaine. Alors bien sûr, 3 erreurs de 1 bit ce n’est pas grand chose (même si c’est déjà une corruption, donc une perte de donnée) mais n’oubliez pas que vous avez aussi 10% de chances de rencontrer 32 erreurs, et 1 pour cent de chance d’en rencontrer 320!

À partir de quel moment le niveau de corruption devient-il inacceptable? À partir de quel moment l’intégrité du système de fichier dans son ensemble est-elle en jeu? Voulez vous essayer? Êtes-vous prêt à risquer 20, 30 To de données?

Voilà pourquoi depuis que les disques de 1 To et plus se sont généralisés, on considère que le RAID-5 présente un risque inacceptable. Le RAID-6 (avec deux parités) constitue la seule manière raisonnable d’agréger des disques de forte capacité.

Les seuls cas où le RAID-5 doit être envisagé sont pour des disques de petite capacité comme les disques SAS de 300 Go, ou pour des disques présentant à la fois une capacité limitée et un taux d’erreur réduit en lecture, les SSD.

Et si on vous propose de stocker vos données sur des grappes de disques SATA 2, 3 ou 4 To en RAID-5, soyez raisonnable: fuyez!

posté à: 16:24 permalink

Mercredi, 29 août 2012

Le RAID hybride: le meilleur des deux mondes (SATA et SSD)

Les disques SSD sont bien plus rapides que les disques magnétiques, mais chers et de capacité limitée. Les disques magnétiques SATA ont de fortes capacités, mais des performances limitées. Mais aujourd’hui on peut avoir fromage et dessert grâce au RAID hybride!

Le système consiste en un RAID-10 mêlant disques SSD et disques magnétiques de forte capacité. La configuration testée est un ST2R doté de 4 SSD 64 Go SATA et de 4 disques 7200t/mn de 3 To.

On obtient deux grappes RAID, une de 256 Gigaoctets ultra-rapide (pour les applications transactionnelles) et une de plus de 8 Téraoctets moins performante ( plus de 400 Mo/s tout de même).

En comparant avec les tests des SSD de l’année dernière, on voit qu’on obtient avec quatre SSD des performances en lecture très proches de celles obtenues avec huit SSD l’an dernier! Sachant que ce sont exactement les mêmes qui ont été utilisé pour les deux tests… On a donc le meilleur du SATA et du SSD: une grosse performance ET une grosse capacité.

posté à: 17:42 permalink

Jeudi, 24 mai 2012

Décodage d’une “press release”: l’évolution des capacités des disques durs

IT Channel nous fait part d’une étude iSuppli sur l’évolution à venir des stockages magnétiques. Plein de bonne volonté, le rédacteur mélange joyeusement les gigabits et les giga-octets ( 1 Go = 8Gb ) mais l’erreur est si commune qu’on la lui pardonne.

Cette étude ne déroge pas aux règles du genre et annonce des chiffres impressionnants ( augmentation de 180019%! toujours plus pour moins cher! ). Mais pour qui sait lire entre les lignes, cette communication de Seagate (qui vaut je suppose, pour les autres, pardon, l’autre constructeur de disques durs) dévoile plus que cela: une inflexion à la baisse de l’augmentation des capacités, qui d’exponentielle de 1980 à 2005, semble de plus en plus prête à atteindre un plateau.

Un petit dessin disant plus qu’un long discours, voyons les projections, en échelle logarithmique et en échelle linéaire (cliquez sur les images pour agrandir).

La projection naïve correspond à la tendance des années 80-90, un doublement de la capacité tous les 18 mois. On constate aisément que cette projection ne correspond plus à la réalité depuis plusieurs années.

La projection corrigée prolonge simplement la tendance des années récentes (2005 à 2012). La courbe reste exponentielle, mais s’infléchit sensiblement (c’est très clair sur l’échelle linéaire).

Mais la projection des valeurs indiquées par iSuppli raconte une histoire toute différente: une nouvelle inflexion vers le bas de la tendance dans les prochaines années! Sur l’échelle logarithmique (chaque graduation valant 10 fois la précédente) c’est très clair: on quitte la tendance exponentielle pour s’approcher du plateau.

Autrement dit: la croissance de la taille des disques va encore ralentir dans les prochaines années. Ce n’est guère étonnant: les constructeurs ont en effet tiré les leçons de la crise de production liée aux inondations en Thaïlande; ils ont réduits les volumes, mais maintenu le chiffre d’affaire tout en augmentant les marges! Peut-être que la formation d’un oligopole planétaire (puisque Western Digital et Seagate totalisent désormais plus de 90% de la production mondiale de disques durs) n’y est pas non plus totalement étrangère.

Conclusion: la communication d’iSuppli nous dévoile le contraire de ce qu’elle semble dire au premier abord, à savoir que les capacités des disques croîtront de moins en moins vite dans les prochaines années.

posté à: 16:58 permalink

Mardi, 15 mai 2012

Les unelignes* (oneliners) perl

Premièrement, l’option -e sur la ligne de commande est suivie d’une chaîne de perl à exécuter immédiatement. Selon l’OS, on préferera mettre le code entre simple ou double guillemets. Un exemple:

perl -e 'print qq/Hello world!\n/;'
Notez l’usage de qq// au lieu de ” (simples guillemets). Étant donné que la chaîne de code est entourée de guillemets simples, ceci évite soit des problèmes avec le shell, soit d’échapper systématiquement les guillemets à l’intérieur du code. Si on utilise les guillemets doubles, attention au shell! Il risque d’interpréter les variables. Le point suivant est l’option -n. -n ouvre chaque fichier passé sur la ligne de commande et en passe chaque ligne au code perl (via $_). Voici un exemple:
perl -n -e 'print qq/$.:\t$_\n/;' textfile.txt
l’exemple précédent parcourt chaque ligne du fichier ‘textfile.txt’ et affiche cette ligne précédée de son numéro de ligne ( c’est ce que contient la varibable spéciale $.). On peut considérer que l’option -n est équivalente à
while( <> ) { ........ }.
Comme une grande partie des unelignes doivent afficher le contenu modifié des fichiers traités, nous pouvons économiser nos petits doigts grâce à l’option -p en lieu et place de -n. L’effet est le même, mais -p rajoute un print $_ implicite à chaque itération de la boucle. Quelque chose comme ça:
while ( <> ) {
    .......... # Votre code ici.
    print $_;
}

Ceci est intéressant pour spécifier une action qui modifie $_ à chaque itération pour afficher le résultat modifié pour chaque ligne. Voici un exemple:

perl -p 's/\bperl\b/Perl/g;' textfile.txt

Ce code va parcourir “textfile.txt” et remplacer toutes les occurences de ‘perl’ par ‘Perl’. Le résultat est envoyé vers STDOUT, à moins que vous ne le redirigiez… Envoyons le vers un autre fichier:

perl -p 's/\bperl\b/Perl/g;' textfile.txt >temptext.txt

Facile, n’est ce pas? Maintenant, mieux. Souvent on voudrait simplement modifier le fichier “sur place”. L’option -i fait exactement cela. Avec l’option -i, on peut soit utiliser -i, ou préciser -i.bak pour indiquer à Perl de créer une copie de sauvegarde du fichier avant de le modifier. L’extension donnée sera ajoutée au nom dufichier; ‘.bak’, ‘.old’, ‘.proutprout’ ou ce que vous voudrez. Voilà comment utiliser l’édition en place:

perl -pi.bak -e 's/\bperl\b/Perl/g' infile.txt

Ce code va parcourir “textfile.txt” et remplacer toutes les occurences de ‘perl’ par ‘Perl’, puis va enregistrer le résultat dans le fichier. Une copie du fichier d’origine sera sauvegardée sous le nom ‘infile.txt.bak’.

Une autre option intéressante est -M. -M équivaut à use ….. par exemple “-MData::Dumper -e “print Dumper \%::” aura le même effet que d’utiliser

use Data::Dumper

dans le bloc de code.

Voilà, nous avons vu les options les plus courantes, on peut déjà en faire beaucoup! La prochaine fois, nous verrons quelques autres options utiles. Et aussi le “baiser eskimo”. Ah ah, je vois les petits curieux…


. * référence évidemment aux fameux “deulignes” de l’immensément regretté HHHHHHHHHebdo (que les moins de 20 ans ne peuvent pas connaître, les pôvres).

posté à: 12:22 permalink

Vendredi, 20 mai 2011

Une nouvelle génération de SSD

Les nouveaux SSD basés sur les contrôleurs SanForce de la famille 1200 présentent une caractéristique intéressante : la déduplication au niveau bloc intégrée dans le contrôleur, une technologie nommée “DuraWrite” par le fabricant.

Pour bien comprendre les avantages de cette nouvelle fonctionnalité, il convient de rappeler comment fonctionnent les SSDs : un tel “disque” peut écrire par “page” de 4Kio, mais doit effacer par bloc de 128 Kio au minimum; par ailleurs un bloc ne peut être écrit et effacé qu’un nombre limité de fois ( pour plus de détails, voir l’article précédent Les promesses du SSD).

La déduplication de bloc signifie qu’avant chaque écriture, le contrôleur vérifie si un bloc identique n’est pas déjà stocké, auquel cas une nouvelle écriture (et potentiellement, un effacement) est évitée. Du coup, la durée de vie est augmentée proportionellement aux écritures évitées; et la performance augmente dans le même rapport, puiqu’on économise sur les opérations les plus coûteuses, l’écriture et surtout l’effacement.

MLC et SLC

Un petit rappel : il existe deux grandes familles de SSD que l’on identifie par l’organisation de la mémoire flash: les MLC et les SLC. Les MLC stockent deux bits par cellule flash, les SLC 1 seul. Le corollaire est qu’à quantité de mémoire égale, un MLC présente le double de capacité. Par contre le SLC est supposé bien plus rapide en écriture, et surtout bien plus durable : les cellules MLC étaient en 2009 données pour capables de 10 000 écritures, contre 100 000 aux SLC.

Cependant les choses évoluent, et les générations actuelles de puces flash MLC sont généralement données pour capables de 100 000 écritures, et 1 000 000 pour les SLC. Autrement dit, les MLC actuelles ont la même durée de vie que les SLC d’il y a deux ans! Voici un premier point.

Second point, quel gain réel nous apporte les nouveaux disques MLC à contrôleur SF1200? Question à laquelle nous nous sommes empressés de répondre par une série de tests.

Le test

Configuration testée :

  • carte-mère Supermicro H8DIi
  • 2 processeurs AMD 2376
  • 16 Go de RAM DDR2 400Mhz ECC Kingston
  • contrôleur RAID Adaptec 5805
  • SSD SLC : 8 SuperTalent UltraDrive GX 64 Go (modèle 2010)
  • SSD MLC : 8 SuperTalent TeraDrive CT 60 Go (modèle 2011)

Les 8 SSD ont été agrégés en une grappe RAID-10 d’une largeur de bande de 16 Ko. Nous avons ensuite effectué une série de 16 tests avec Bonnie++.

Tout d’abord, le test d’accès séquentiel : écriture, lecture et écriture simultanées, lecture :

ssd comp read write

Les SSD MLC sont en fait nettement plus performants que les SLC de l’année dernière : 590 Mo/s en écriture contre 200 Mo/s; 1150 Mo/s en lecture contre 600 Mo/s!

Ensuite, le test de création, accès et suppression de fichiers, séquentiel puis aléatoire, en augmentant le nombre de fichiers pour le test à 80 000:

ssd comp file

L’écart est assez peu significatif. Il faut dire que le contrôleur RAID lui-même est probablement assez proche de sa performance crête autour de 45 000 IOPS. Cependant le MLC est encore nettement gagnant.

Pour le test simulant des accès de base de données (accès aléatoires de 8 Ko) les SSD MLC ont également été testés en RAID-6 (bande 64 Ko), RAID-5 (bande 16 Ko), RAID-10 (bande de 256 Ko). L’accès en écriture seule a également été testé. En abscisse, nous avons le nombre d’accès parallèles (threads), en ordonnée le nombre d’opérations par seconde:

ssd comp db

On constate là encore une forte supériorité du MLC, qui sature les capacités du contrôleur. Il n’y a pas d’écart important entre le RAID-5 et le RAID-6, et le RAID-10 n’apporte pas plus de 10% de gain. On peut raisonnablement envisager de faire des économies et d’utiliser ces SSD en RAID-5 ou RAID-6 sans arrière-pensée, même (sacrilège!) pour de la base de données.

On remarque que la performance en écriture aléatoire est nettement inférieure à la lecture, ce qui est attendu. On relativisera cependant en pensant que pour obtenir cette performance ( 14 700 IOPS, 47 Mo/s) en accès aléatoire avec des disques “en métal rouillé” il faut environ 60 disques SAS 15000 tours/minute, et 120 disques SATA 7200 tours/minute.

posté à: 17:16 permalink

Lundi, 03 janvier 2011

Deduplication in StorIQ 3.0 : setup and data

Some people wanted some more information on the test setup used in the deduplication benchmarks, so here are some more details :

  • dual Opteron 2376 system
  • 16 GB RAM
  • 2 Adaptec 52445 RAID controllers
  • 24 Hitachi Ultrastar 2 TB drives in 2 RAID-6 arrays, 64KB stripe.
  • Kernel Linux 2.6.32.11 AMD64 (custom built from vanilla www.kernel.org source)
  • RAID arrays agreggated with LVM and mounted as an XFS filesystem.
  • Lessfs 1.1.9.10

Here are the bonnie++ results (meaningless and empty columns removed). You can clearly see the very low LessFS metadata performance (though Lessfs 1.2.x improves on this, more benchmarks to come).

nameput_blockrewriteget_blockseeksran_del
XFS8641073938361048367555,528255
XFS8856543923541076189556,325665
XFS8124713950101109478563,528611
XFS826676389504974248573,728056
lessfs114409535632180813090,824
lessfs127666718522254723165,623
lessfs124484736382163171720,423
lessfs124739732792247262427,523

The block performance results are drawn below :

benchmark results

As you can see, deduplicated performance is more than enough to saturate a 1 Gb network. For more performance hungry users, it will be a great secondary storage. Notice that it’s possible to both have your cake and eat it as you might use both XFS — for maximum performance — and Lessfs — for maximum capacity — storage simultaneously.

Happy New Year!

posté à: 19:06 permalink

Mercredi, 22 décembre 2010

Deduplication in StorIQ 3.0

I tested various real-time online deduplication implementations at the filesystem level under Linux, namely Opendedup, Lessfs and a couple of proprietary ones. What’s great of course is that it’s transparent, you can share data using all protocols at once (NFS, CIFS, iSCSI, FTP, whatever), namely you can use your dedupe filesystem exactly like an ordinary one.

The only concern can be about performance and particularly IOPS; Some systems get decent throughput but in any case the IOs are all basically turned into random IOs, therefore dedupe hurts performance badly any way you turn it.

Some will ask : why are all IOs made random? Because while you’re sending data to the “deduplicator”, it checksums blocks of data as they’re coming and compares them against its hash index of blocks, throwing away any block previously seen. If the filesystem is big, this database won’t fit in memory and will be continuously scanned while writing so the disk access pattern is basically write a bit sequentially, read the index, write some more data, read the index…

Reading is a different matter; we suppose that about half the data is not unique, so when you’re reading some sequential data, you’re actually reading blocks written at different times and as such physically scattered around the disks. So reading is almost certainly quasi random, limiting seriously performance.

Example from real benchmarks : I created 60 TB of semi-randomized data, occupying a total of 19 TB after combined compression/dedupe. The filesystem performance without dedupe is about 350 MB/s write, 500 MB/s read, 1500 IOPS. With dedupe the figures are 120 MB/s write (but it varies extremely from 30 MB/s to 300 at times) and 200 MB/s read; however IOPS drop to an abysmal 40 to 50.

My conclusion is that it’s not generally commendable as a primary storage application; however as a “warm” archive or backup, or for rarely accessed files, it’s wonderfully effective.

posté à: 17:01 permalink

Jeudi, 30 septembre 2010

L’essor de “moins bien, c’est mieux”, par Richard Gabriel (1987).

D’après The rise of Worse is Better.

À peu près tous les concepteurs de Common LISP et CLOS, dont moi-même, ont été extrêmement exposés au style de conception du MIT/Stanford. L’essence de ce style peut être rendue par la phrase : “ce qu’il faut”. Pour un tel concepteur, il est important de réussir à obtenir ces caractéristiques:

  • simplicité - la conception doit être simple, en implémentation comme en interface. Il est plus important pour l’interface d’être simple que pour l’implémentation.
  • exactitude. La conception doit être correcte dans tous les aspects observables. L’inexactitude n’est simplement pas autorisée.
  • Cohérence. Le modèle ne doit pas être incohérent. La conception peut être légèrement moins simple et moins complète pour éviter les incohérences. La cohérence est aussi importante que l’exactitude.
  • Complétude. La conception doit gérer autant de situations importantes que possible. Tous les cas raisonnablement envisageables doivent être couverts. La simplicité n’est pas autorisée aux dépens de la complétude.

Je pense que la plupart des gens admettront que ce sont de bonnes caractéristiques. J’appellerai l’usage de cette philosophie dans la conception “l’approche MIT”. Common LISP (y compris CLOS) et Scheme représentent l’approche MIT dans la conception et l’implémentation.

La philosophie “moins bien, c’est mieux” diffère subtilement:

  • simplicité. la conception doit être simple, en implémentation comme en interface. Il est plus important pour l’implémentation d’être simple que pour l’interface. La simplicité est la plus importante considération dans un concept.
  • Exactitude. La conception doit être correcte dans tous les aspects observables. Il est plus important d’être simple que correct.
  • Cohérence. La conception ne doit pas être incorrecte de manière trop évidente. La cohérence peut être sacrifiée à la simplicité dans certains cas, mais il est préférable d’abandonner les parties qui concernent les circonstances moins courantes que d’introduire soit plus de complexité dans l’implémentation, soit des incohérences.
  • Complétude. La conception doit gérer autant de situations importantes que possible. Tous les cas raisonnablement envisageables devraient être couverts. La complétude peut être sacrifié au profit de toute autre qualité. En fait, la complétude doit être sacrifiée quand la simplicité d’implémentation est en jeu. La cohérence peut être sacrifié pour atteindre la complétude si cela permet de maintenir la simplicité; la cohérence de l’interface n’a pas de valeur particulière.

Les anciennes versions d’Unix et de C sont des exemples de cette école de conception, et j’appellerai cette stratégie “l’approche New Jersey”. J’ai intentionnellement caricaturé la philosophie du “moins bien, c’est mieux” pour vous convaincre que c’est de toute évidence une mauvaise philosophie et que l’approche New jersey est une mauvaise approche.

Cependant, je crois que le “moins bien, c’est mieux”, même présenté comme un épouvantail, a de meilleures capacités de survie que “ce qu’il faut”, et que l’approche New Jersey appliquée au logiciel est supérieure à l’approche MIT.

Permettez moi de répéter une histoire qui montre la validité de la distinction entre MIT et New Jersey, et que les promoteur de chacune de ces philosophies pensent réellement que leur philosophie est la meilleure.

Deux fameux personnages, l’un du MIT et l’autre de Berkeley (mais travaillant sur Unix) se rencontraient pour discuter de problèmes de systèmes d’exploitation. La personne du MIT connaissait bien ITS (le système d’exploitation du labo d’intelligence artificielle du MIT) et avait lu les sources d’Unix. Il voulait savoir comment Unix résolvait le problème du contrôle de processus “loser”. Ce problème apparaît lorsqu’un programme utilisateur invoque une routine système pour effectuer une opération de longue durée qui peut avoir un état significatif, comme des tampons d’entrée-sortie. Si une interruption se produit pendant cette opération, l’état du programme utilisateur doit être sauvegardé. Comme l’invocation de la routine système est généralement une seule instruction, le contrôle de processus du programme ne peut capturer de manière adéquate l’état du processus. La routine système doit donc soit ressortir, soit continuer sur sa lancée. “Ce qu’il faut” est ressortir, restaurer le programme utilisateur à l’instruction précise qui a invoqué la routine système afin qu’à la reprise du programme utilisateur après l’interruption, par exemple, on rentre à nouveau dans la routine système. On appelle cela contrôle de processus “loser” parce que le contrôle de processus est forcé en mode “loser”, “loser” étant le petit nom pour “utilisateur” au MIT.

Le gars du MIT ne voyait aucun code pour prendre soin de ce cas et demanda au gars du New Jersey comment le problème était pris en charge. Le gars du New Jersey répondit que les gens d’Unix étaient conscients du problème, mais que la solution était pour la routine système de toujours finir, mais parfois un code d’erreur serait retourné pour signaler que la routine avait échoué à terminer son action. Un programme utilisateur correct, donc, devait vérifier le code d’erreur pour déterminer s’il devait simplement essayer d’appeler la routine système à nouveau. Le gars du MIT n’aimait pas cette solution parce que ce n’était pas “ce qu’il faut”.

Le gars du New jersey dit que la solution Unix était correcte, parce que la philosophie de conception d’Unix était la simplicité et que “ce qu’il faut” serait trop complexe. Par ailleurs, les programmeurs pouvaient facilement ajouter ce test et cette boucle supplémentaires. Le gars du MIT remarque que l’implémentation était simple mais que l’interface de la fonctionnalité était complexe. Le gars du New Jersey fit alors que le bon compromis avait été choisi dans Unix, à savoir la simplicité d’implémentation était plus importante que la simplicité de l’interface.

Le gars du MIT marmonna alors que parfois il faut être un vrai dur pour faire un poulet bien tendre, mais le gars du New Jersey n’a pas compris (je ne suis pas sûr d’avoir compris non plus).

Maintenant je veux arguer le fait que “moins bien c’est mieux” est mieux. C est un langage de programmation conçu pour écrire Unix, et il a été conçu en suivant l’approche New Jersey. C est par conséquent un langage pour lequel il est facile d’écrire un compilateur acceptable, et il impose au programmeur d’écrire du texte facile à interpréter par le compilateur. Certains ont dit que le C était un langage assembleur sophistiqué. À la fois les anciens Unix et compilateurs C avaient des structures simples, étaient facile à porter, demandaient peu de ressources machine pour s’exécuter, et fournissaient à peu près 50 à 80 % de ce que l’on attend d’un système d’exploitation et d’un langage de programmation.

La moitié des ordinateurs existant à un instant quelconque sont inférieurs à la moyenne (plus petits, plus lents). Unix et C fonctionnent bien sur ceux-ci. L’approche “moins bien, c’est mieux” signifie que la simplicité d’implémentation a la plus haute priorité, ce qui veut dire qu’Unix et C sont faciles à porter sur de telles machines. Par conséquent, puisque les 50% de fonctionnalité fournies par C et Unix sont satisfaisants, on s’attend à ce qu’ils commencent à apparaître partout. Et c’est bien ce qu’il s’est passé, n’est ce pas?

Unix et C sont les virus informatiques ultimes.

Un bénéfice supplémentaire de l’approche “moins bien, c’est mieux” est que le programmeur est conditionné à sacrifier de la sûreté, de la commodité et des ennuis pour obtenir une bonne performance et une utilisation modeste de ressources. Les programmes écrits en utilisant l’approche New Jersey fonctionneront bien sur de petites machines comme sur des grosses, et le code sera portable puisqu’il est écrit par dessus un virus.

Il est important de se rappeler que le virus initial doit être globalement bon. Dans ce cas, la propagation virale est assurée aussi longtemps qu’il reste portable. Une fois que le virus s’est répandu, on fera pression pour l’améliorer, peut-être en augmentant la fonctionnalité plus près de 90%, mais les utilisateurs ont déjà été habitué à accepter quelque chose d’inférieur à “ce qu’il faut”. En conséquence, le logiciel “moins bien c’est mieux” premièrement commencera à être accepté, deuxièmement habituera les utilisateurs à en attendre moins, et troisièmement sera amélioré jusqu’au point où il sera presque comme il faut. En terme concrets, bien que les compilateurs Lisp en 1987 aient été à peu près aussi bons que les compilateurs C, il y a nettement plus d’experts en compilateurs qui veulent améliorer les compilateurs C que les compilateurs Lisp.

La bonne nouvelle c’est qu’en 1995 nous auront un bon système d’exploitation et un bon langage de programmation; la mauvaise nouvelle c’est que ce seront Unix et C++.

Il y a un dernier avantage à “moins bien c’est mieux”: Comme le système et le langage du New Jersey ne sont pas vraiment assez puissants pour construire de grands et complexes logiciels monolithiques, les grands systèmes doivent être conçu pour réutiliser des composants. Par conséquent une tradition d’intégration fleurit.

Comment “ce qu’il faut” se défend-il? Il y a deux scénarios de base : le scénario du “grand système complexe” et celui du “pur joyau”.

Le scénario du “grand système complexe” se déroule ainsi:

Tout d’abord, le système “qu’il faut” doit être conçu. Ensuite l’implémentation doit en être conçue. Enfin il est implémenté. Comme c’est “ce qu’il faut”, il a pratiquement 100% de la fonctionnalité souhaitée, et la simplicité d’implémentation n’ayant pas été une préoccupation cela a pris très longtemps. Le système est vaste et complexe. Il nécessite des outils complexes pour l’utiliser correctement. Les derniers 20% prennent 80% de l’effort, et de fait “ce qu’il faut” prend du temps, et ne fonctionne correctement que sur le matériel le plus sophistiqué.

Le scénario du “pur joyau” se déroule ainsi:

La conception de “ce qu’il faut” demande une éternité, mais le système est plutôt compact. L’implémenter de façon à ce qu’il soit rapide est soit impossible, soit au-delà des capacités de la plupart des développeurs.

Ces deux scénarios correspondent à Common Lisp et Scheme.

Le premier scénario est aussi celui des logiciels d’intelligence artificielle classique.

“Ce qu’il faut” est fréquemment un logiciel monolithique, mais sans raison autre que sa conception est menée ainsi. De fait cette caractéristique est accidentelle.

La leçon à retenir de tout ceci est qu’il est souvent indésirable de commencer par “ce qu’il faut”. Il est préférable d’avoir la moitié de “ce qu’il faut” disponible afin qu’il se répande comme un virus. Une fois que les gens s’y sont attachés, prenez le temps de l’améliorer jusqu’à 90% de “ce qu’il faut”.

La leçon à ne surtout pas retenir serait de prendre cette parabole littéralement et d’en conclure que C est le bon véhicule pour l’intelligence artificielle. La solution à 50% doit être à peu près juste, et dans ce cas elle ne l’est pas.

Mais on peut aussi conclure que la communauté Lisp doit sérieusement reconsidérer sa position sur la conception en Lisp. J’en dirai plus sur ce sujet ultérieurement.

rpg@lucid.com

posté à: 14:47 permalink

Lundi, 27 septembre 2010

Maître Foo et les dix mille lignes

Un jour, maître Foo dit à un programmeur en visite: “Il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

Le programmeur, qui était très fier de sa maîtrise du C, dit :”Comment est-ce possible? C est le langage dans lequel est écrit le noyau même d’Unix!”.

Maître Foo repondit: “Cela est vrai. Néanmoins, il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

La détresse gagnait le programmeur : “Mais à travers le langage C nous expérimentons l’illumination du Patriarche Ritchie! Nous ne faisons plus qu’un avec le système d’exploitation et la machine, atteignant des performances sans égales!”

Maître Foo repondit: “Tout ce que tu dis est vrai. Mais il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

Le programmeur fit une grimace et se leva pour partir. Mais Maître Foo fit un signe de tête vers son étudiant Nubi, qui écrivit une ligne de script shell sur le tableau blanc tout proche et dit : “Maître programmeur, considérez ce tube (“pipe”). Implémenté en C, ne ferait-il pas près de dix mille lignes?”

Le programmeur marmonna dans sa barbe, en contemplant ce qu’avait écrit Nubi. Finalement, il admit qu’il en était ainsi.

“Et combien d’heures vous faudrait-il pour écrire et déboguer ce programme C?” demanda Nubi.

“Beaucoup.” admit le visiteur. “Mais seul un imbécile y passerait son temps alors que l’attendent de nombreuses tâches plus importantes.”

“Et qui comprend mieux la nature d’Unix?” demanda Maître Foo. “Celui qui écrit dix mille lignes, ou celui qui percevant la vacuité de la tâche, gagne en mérite en ne codant pas?”

Entendant cela, le programmeur fut illuminé.

d’après Rootless Root, the Unix koans of Master Foo.

posté à: 19:24 permalink

Mercredi, 08 septembre 2010

Situation tendue entre Oracle et HP

Suite à l’embauche de l’ex patron d’HP Mark Hurd par Oracle, HP attaque son ex-employé en justice. Le moins que l’on puisse dire est que Larry Ellison n’a pas l’air content, si on en croit le communiqué de presse d’Oracle. En voici une traduction rapide :

“Oracle a longtemps considéré HP comme un partenaire important”, a déclaré Larry Ellison, CEO d’Oracle. “En émettant cette attaque en justice vindicative contre Oracle et Mark Hurd, le conseil d’administration d’HP agit avec un mépris complet de ce partenariat, de nos clients communs, de leurs actionnaires et employés. Le conseil d’administration d’HP rend virtuellement impossible pour Oracle et HP de continuer à coopérer et travailler ensemble sur le marché informatique (souligné par nous).

On peut affirmer sans trop s’avancer qu’il va y avoir du sport.

posté à: 11:59 permalink

Mardi, 07 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Magicien

  • Tutoie la femme de Larry.
  • A écrit ou récrit des parties majeures du compilateur ou de l’interpréteur Perl.
  • Pense récrire le moteur d’expressions régulières, l’allocateur de mémoire ou le ramasse-miettes.
  • N’écrit pas de jeux en Perl, parce qu’il a réalisé que Perl lui-même est un jeu.

posté à: 18:30 permalink

Lundi, 06 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Gourou

  • Peut répondre à toute question sur Perl instantanément.
  • Peut tout écrire en Perl - et le fait.
  • Exploite des fonctionnalités non documentées du langage.
  • Écrit du code qui étonne même Larry.
  • Implémente des objets opaques et des regexps compilées en utilisant les “clôtures”.
  • Peut lire et comprendre la sortie du compilateur perl en C.
  • Embarque des interpréteurs Perl dans de grosses applications.
  • A écrit son propre module de débogage -d:.
  • A utilisé la programmation orientée-objet avant même qu’elle existe.
  • Discute avec le Pumpking de prendre son tour (encore).

posté à: 18:30 permalink

Dimanche, 05 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Hacker

  • Écrit des jeux en Perl.
  • A écrit des modules d’extension en C.
  • Utilise AUTOLOAD et les clôtures de façon originale.
  • Apprécie en esthète la “Schwartzian transform”.
  • Se régale de la flexibilité du système d’objets de Perl.
  • A écrit son propre traducteur pod vers X.
  • Comprend la sortie de Perl -D.
  • Accède directement à la table des symbôles Perl.
  • Soumets des rapports de bogues avec des patchs fonctionnels.
  • Édite des fichiers en utilisant une version spéciale de vi ou emacs embarquant Perl.
  • A écrit des modules, des pages de manuel et des outils de la distribution standard de Perl.

posté à: 18:30 permalink

Samedi, 04 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Expert

  • Écrit des JAPHs pout impressioner ses amis et embêter ses collègues.
  • Commence tous ses programmes par use strict.
  • Pense que Perl doit seulement être Perl.
  • A suffisemment utilisé les contextes implicites à son avantage pour ennuyer d’autres gens.
  • Sait comment créer des enregistrements et des objets avec des hashrefs.
  • Utilise syscall pour atteindre un appel système non documenté.
  • Maudit la flexibilité du système d’objets de Perl.
  • utilise /e dans les substitutions.
  • A commencé à se demander à quoi peuvent bien servir les typeglobs.
  • A écrit ses propres modules en Perl.
  • Commence à envisager toutes les données en termes d’expressions régulières.
  • Comprend pourquoi les regexps ne peuvent pas analyser des données imbriquées.
  • Récrit des petits utilitaires en Perl.

posté à: 18:30 permalink

Vendredi, 03 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Utilisateur

  • Pense que Perl sert seulement à manipuler du texte.
  • Utilise le débogueur Perl.
  • A utilisé des modules d’autres gens.
  • Se demande ce qu’est un objet.
  • Sait se diriger sur CPAN.
  • Sait la différence entre local et my.
  • Pense que Perl devrait plus ressembler à scheme ou eiffel.
  • Soumet de vrais rapports de bugs avec perlbug.

posté à: 18:30 permalink

Jeudi, 02 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Initié

  • A commencé d’apprendre l’usage de $_ - et n’aime pas ça du tout.
  • Pense que use warnings est une perte de temps.
  • Pense que Perl devrait plus ressembler à C++ ou Java.
  • Essaie toujours de saisir pourquoi Perl a deux sortes de tableaux.
  • Say comment utiliser perlbug, mais envoie de faux rapports.
  • A souffert des conversions de contexte implicites, mais ne l’a pas encore réalisé.
  • Ne distingue pas == de eq, et pense que + devrait concaténer les chaînes.

posté à: 18:30 permalink

Mercredi, 01 septembre 2010

Les sept niveaux de Maîtrise de Perl

d’après Seven levels of Perl Mastery

Novice

  • Pense que CGI et Perl sont des termes interchangeables.
  • Pense encore que Perl ressemble à du mauvais code C transmis sur une ligne bruitée.
  • est incertain de l’usage du signe dollar.
  • Pense que Perl devrait plus ressembler à sh ou tcl.
  • A entendu parlé de “l’état d’esprit Unix”, mais espère que ça se soigne.
  • Ne trouve pas comment lire des données depuis le clavier.
  • Pense que les expressions régulières sont des insultes.
  • Se demande pourquoi ne lui répond clairement si Perl est compilé ou interprété.

posté à: 18:30 permalink

Dimanche, 29 août 2010

Le Tao de la Sauvegarde, Épilogue.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4 chapitre 5 chapitre 6 chapitre 7

Épilogue.

Le novice venait de terminer la vérification d’une sauvegarde de tous ses fichiers, qu’il surveillait maintenant avec un outil de contrôle d’intégrité. C’était la cinquième sauvegarde de la semaine, et il l’avait contrôlée en la restaurant, puis en vérifiant les données restaurées avant de l’enfermer à clef dans une armoire au loin, avec les sauvegardes des mois précédents.

Le novice dit “Maintenant que j’ai la complétude, la fréquence, la séparation, l’historique, la vérification, la sécurité et l’intégrité, je dois bien avoir atteint l’illumination?”

Le maître dit: “Tu n’es pas encore illuminé, mais tu es sur les dernières marches de l’échelle qui y conduit. La prochaine étape est d’acheter plus de mes solutions de sauvegarde.”

Le novice devint suspicieux et dit : “Maître, est-ce que tout ce Tao de la Sauvegarde n’est pas un prétexte pour vendre vos solutions?”

Le maître répondit : “Maintenant, tu as vraiment connu l’illumination.”

Les sauvegardes sont importantes.

posté à: 08:50 permalink