storiq logo

La traînée de poudre

Le blog StorIQ

 

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

Samedi, 28 août 2010

Le Tao de la Sauvegarde, chapitre 7.

D’après www.taobackup.com

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

Intégrité.

Le novice s’impatientait sur la route de l’illumination. “Maître, en tant que disciple du Tao, je sauvegarde régulièrement tous mes fichiers. Je les archive en sûreté, au loin, puis je vérifie leur intégrité. Sans doute suis-je maintenant illuminé, maître?”

Le maître des sauvegardes dit seulement : “Tu n’achèveras pas l’illumination tant que tu ne contrôleras pas l’intégrité de tes données mêmes, car une copie est inutile si l’original est corrompu. À quoi sert un miroir si nous ne voyons pas? À quoi sert un écho si nous n’entendons pas?” Mais le novice ne comprenait pas.

Plus tard, le novice revint. “Maître,” dit-il, “un pirate sur internet a pénétré mon réseau il y a six mois et a corrompu des fichiers au hasard depuis lors. Des centaines de fichiers corrompus se sont répandus dans mon système de sauvegarde. Maintenant je ne sais lesquels sont valides et lesquels ne le sont pas. J’ignore quelle sauvegarde contient la dernière copie inaltérée de chaque fichier. Que dois-je faire?”

Mais le maître restait silencieux.

De l’autre côté de la terre, le pirate riait.

Contrôlez l’intégrité des données.

posté à: 08:50 permalink

Vendredi, 27 août 2010

Le Tao de la Sauvegarde, chapitre 6.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4 chapitre 5

Sécurité.

Le maître des sauvegardes rendait visite au novice qui venait de terminer l’installation d’un système de sécurité réseau pour sa société.

“Voyez,” dit le novice, “notre sécurité est totale. Nous avons installé le plus sévère des pare-feux. Toute notre équipe a été entraînée à n’utiliser que des mots de passe obscurs et à ne les dévoiler à quiconque. Nous surveillons tout le trafic du réseau et nos courriels sont chiffrés. Nos données sont en sûreté, à l’abri de toute divulgation.”

Le maître se tint coi, mais sur le chemin de la sortie il empocha une cartouche de sauvegarde de la société totalisant 400 Go, qui traînait par là.

Plus tard, il l’expédia au novice.

Mettez vos sauvegardes en sûreté.

posté à: 08:50 permalink

Jeudi, 26 août 2010

Le Tao de la Sauvegarde, chapitre 5.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4

Vérification.

Le novice demanda au maître des Sauvegardes : “Maître, maintenant que mes sauvegardes sont complètes, que je les fais fréquemment, que je les archive et les disperse aux quatre coins de la terre, j’ai une confiance suprême en elles. Ai-je atteint l’illumination? Sans doute ai-je compris maintenant le Tao de la Sauvegarde?”

Le maître se tint immobile pendant une minute, puis soudain il brandit une hache et broya le disque dur du novice en morceaux. Puis il dit calmement : “Croire en ses sauvegardes est une chose. Avoir à les utiliser en est une autre.”

Le novice avait l’air fort inquiet.

Vérifiez vos sauvegardes.

posté à: 08:50 permalink

Mercredi, 25 août 2010

Le Tao de la Sauvegarde, chapitre 4.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3

Historique

Le novice porta au maître une vieille cartouche de sauvegarde et demanda :”Maître, cette bande a plus de six mois. Si je veux atteindre la perfection terrestre, n’est-il pas juste de la réutiliser?”

Le maître prit la cartouche et dit : “Je la réutiliserai. Maintenant hâte-toi, va examiner ton disque dur.”

Le novice examina son disque et découvrit qu’un virus avait corrompu des centaines de fichiers importants mais peu utilisés. Il chargea la sauvegarde de la veille, mais ces fichiers étaient aussi corrompus. Il chargea une sauvegarde datant d’une semaine, mais elle était comme la précédente. Éventuellement, il réalisa que le virus avait frappé quatre mois plus tôt. Il retourna voir le maître et lui dit: “Maître, vous avez la seule copie non corrompue!”

Mais le maître avait déjà récrit la bande avec une copie de DOOM.

Le maître dit : “De même que nous respectons et prenons soin de nos ancêtres, nous devons respecter et prendre soin de nos anciennes sauvegardes, parce qu’un jour elle peuvent atteindre une grande gloire.”

Conservez d’anciennes sauvegardes.

posté à: 08:50 permalink

Mardi, 24 août 2010

Le Tao de la Sauvegarde, chapitre 3.

D’après www.taobackup.com

chapitre 1 chapitre 2

Séparation

Le novice demanda au maître des Sauvegardes : “Maintenant que je sauvegarde régulièrement tous mes fichiers, suis-je illuminé dans la voie de la Sauvegarde?”

Le maître répondit :”En sauvegardant tous tes fichiers tu es sur la voie de l’illumination, mais tu ne l’atteindras qu’en répandant tes sauvegardes aux quatre coins du monde. Le pissenlit laisse-t-il choir toutes ses graines à son pied? Le coucou pond-il tous ses oeufs dans le même nid? Aussi longtemps que tes sauvegardes sont en un seul endroit, tu es vulnérable aux caprices de la fortune.”

Mais le novice n’écoutait pas, et cette nuit-là, le bâtiment brûla jusqu’au fondations, détruisant l’ordinateur du novice et toutes ses bandes de sauvegarde. Le novice vint vers le maître et dit “Maître, j’ai perdu tous mes fichiers. Que dois-je faire?”

Le maître dit “Ne désespère pas, car hier j’ai pris une de tes bandes de sauvegarde et je l’ai expédiée à mon frère en Chine. Il la renverra.”

Ce ne fut que plus tard qu’il dit au novice qu’il l’avait envoyé par fret maritime.

Conservez quelques sauvegarde au loin.

posté à: 08:50 permalink

Lundi, 23 août 2010

Le Tao de la Sauvegarde, chapitre 2.

D’après www.taobackup.com

chapitre 1

Fréquence

Le novice demanda au maître des Sauvegardes : “À quelle fréquence dois-je sauvegarder mes fichiers? Un mois s’est écoulé depuis ma dernière sauvegarde.”

Le maître répondit : “Comme la nuit suit le jour, et l’automne suit l’été, ainsi les sauvegardes suivent le travail. Chaque fois que tu travailles, tu dois sauvegarder le fruit de ton labeur.”

Le novice dit:”Je travaille chaque jour.”

Le maître répondit:”Alors tu dois sauvegarder chaque jour.”

Le novice reprit: “Je suis d’accord, mais pour l’instant je n’ai pas le temps d’effectuer une sauvegarde, j’ai bien trop de travail à accomplir.”

À ces mots, le maître se tint coi.

Sauvegardez fréquemment.

posté à: 08:50 permalink

Dimanche, 22 août 2010

Le Tao de la Sauvegarde, chapitre 1.

D’après www.taobackup.com

Un novice voulait connaître le Tao de la Sauvegarde. Le maître lui dit: “Pour connaître l’illumination, tu dois maîtriser les sept voies de la Sauvegarde. Celui qui connaît les sept voies conservera ses données pour toujours. Celui qui ne les connait pas perdra tout.” Et ainsi commença la leçon.

Complétude

Le novice demanda au maître quels fichiers sauvegarder. Le maître dit : “Comme le berger surveille toutes les brebis de son troupeau, comme la lionne garde l’oeil sur tout ses lionceaux, ainsi tu dois sauvegarder tous les fichiers sous ta garde, quelle que soit leur importance. Parce que même le plus petit fichier peut prendre des jours à recréer.”

Le novice répondit : “Je sauvegarderai tous mes documents de travail, mais pas mon système, ni les applications, car je peux toujours les réinstaller depuis leurs supports d’origine.”

Le maître ne répondit pas.

Le jour suivant, le disque du novice fit un atterrissage de tête. Trois jours plus tard, le novice était encore occupé à réinstaller des logiciels.

Sauvegardez TOUTES vos données.

posté à: 08:50 permalink

Mercredi, 18 août 2010

Le futur de Solaris

L’attaque d’Oracle contre Google à propos de sa plateforme Dalvik permet de revenir sur le passé récent et s’interroger sur l’avenir de l’héritage Sun au sein d’Oracle, en particulier les nombreuses applications libres et à source ouvertes, à savoir :

  • OpenSolaris
  • Java
  • MySQL
  • OpenOffice, VirtualBox

Le futur d’OpenSolaris

Ne le nions pas, il est plus que sombre. D’une part Oracle semble se désintéresser singulièrement de Solaris, en ne communiquant guère sur ses évolutions. Ils ont finalement annoncé cette semaine qu’une nouvelle version apparaîtrait en 2011, après de longs mois d’un silence inquiétant.

Quant à OpenSolaris, c’est l’abandon pur et simple : les ressources de développement ont été supprimées, la version prévue en mars 2010 n’a pas vu le jour, et malgré une mise à jour des sources, la version “officielle” a été officiellement abandonnée . Du coup, la (petite) communauté OpenSolaris tente de lancer un “fork”, pour ne pas rester otage du bon vouloir d’Oracle, mais c’est là que se profile une autre ombre menaçante…

NetApp vs CoRaid

Il y a quelques semaines, NetApp a envoyé une lettre de menaces (disons le mot) au petit constructeur CoRaid (développeur du ATA-over-Ethernet), pour l’obliger à retirer de la vente ses appliances sur base d’OpenSolaris. La source du problème : ZFS.

NetApp a en effet attaqué Sun en justice, pour violation de brevets (concernant le système de fichier NetApp, WAFL). Or si Sun se porte garant des utilisateurs de Solaris (la version commerciale), il n’en est pas de même pour OpenSolaris; bien au contraire, la licence CDDL exclut explicitement la violation des brevets de la responsabilité de Sun…

La licence d’OpenSolaris en général et de ZFS en particulier interdisant de faire appel à la protection d’Oracle (c’est de bonne guerre), NetApp est apparemment nettement décidé à empêcher quiconque d’exploiter ZFS commercialement, et ils en ont clairement les moyens.

Petit aparté : ceci explique sans doute pourquoi Oracle a subitement supprimé la possibilité de télécharger et mettre à jour Solaris (la version commerciale) gratuitement: Oracle ne peut guère se permettre de protéger des utilisateurs sans compensation financière, maintenant que la menace se fait bien réelle.

L’odeur du sapin

Conclusion évidente : le principal attrait d’OpenSolaris étant ZFS, OpenSolaris est bel et bien mort, en tout cas définitivement condamné à rester un outil de hobbyiste ou d’administrateur système, sans aucun avenir commercial. Les tentatives de Nexenta et quelques autres de créer des “forks” sont certainement sans avenir. Sic transit gloria mundi.

La semaine prochaine : Oracle vs Google, le choc des titans.

posté à: 15:43 permalink

Vendredi, 13 août 2010

Les promesses du SSD.

Les disques SSD existent depuis longtemps, mais il n’y a que récemment qu’ils sont enfin devenus à la fois relativement courants, peu coûteux et fiables. Intellique installe des serveurs avec des disques SSD depuis plus de deux ans déjà, et quelle évolution dans ce laps de temps!

De nombreux passionnés de techno ( qui a dit “geeks”? ) cependant, sont déjà impatients de voir les nouvelles fonctionnalités que promettent les constructeurs, en particulier :

  • la commande TRIM et le “Garbage Collector”
  • l’interface SATA3

Je me dois donc de vous expliquer tout d’abord ce que sont ces fonctionnalités, ensuite à quoi elles servent, ensuite pourquoi nous ne les proposons pas déjà :)

La fonction TRIM

La commande TRIM permet de demander explicitement à un SSD d’effacer un bloc de données. Il faut savoir qu’un SSD peut écrire généralement des blocs de 4 Kio (appelés pages), mais ne peut effacer que des blocs de 128 Kio ou plus. Ceci peut réduire drastiquement les performances en écriture lorsqu’on modifie des blocs précédemment écrits : en effet, avant de pouvoir écrire telle page de 4 Kio, il faut relire le bloc de 128 Kio auquel elle appartient, le modifier dans une mémoire cache, l’effacer puis le récrire entièrement. On se retrouve donc à lire 124 Kio, effacer le bloc puis écrire 128 Kio pour effectivement modifier 4 Kio… soit à manipuler 64 fois plus de données que prévu, entraînant par là une réduction équivalente de la performance.

Comment pallier ce grave problème? les constructeurs de disques SSD rivalisent d’ingéniosité pour éviter d’avoir à récrire un bloc déjà alloué. Cependant la seule bonne solution réside au niveau du système d’exploitation, qui lui choisit quels blocs utiliser et comment. Cependant, pour tirer la quintessence des SSD, il faut profondément modifier la manière dont nos systèmes de fichiers organisent les données. En fait, il faut même utiliser de nouveaux systèmes de fichiers optimisés pour cela.

C’est là qu’entre en jeu la commande TRIM. Un système de fichier optimisé pour l’utilisation de SSD peut allouer les blocs de manière à éviter les réécritures, et d’autre part demander au disque d’effacer certains blocs de façon à libérer de l’espace en avance plutôt qu’au moment précis où l’on en a besoin. C’est justement ce qu’on appelle un “ramasse miettes”, en anglais “Garbage collector”.

Et nous touchons le premier point délicat : pour utiliser la commande TRIM à bon escient, il faut un nouveau système de fichiers. Adieu, les bons vieux NTFS, ext3 et autres HFS+. On conçoit l’ampleur du problème : vu la difficulté à se débarrasser des scories de MS-DOS et de FAT32, quand les éditeurs seront-ils prêts? Et bien, pas avant un certain ( et même très certain ) temps.

La fonction TRIM et le stockage professionnel

Mais il y a pis : si on peut espérer voir poindre bientôt ( un an? 18 mois?) des solutions matures pour les disques durs SSD destinés aux ordinateurs portables, le problème est encore bien plus épineux en ce qui concerne le stockage d’entreprise. En effet, dans ce cas on utilise les disques ( SSD ou pas ) en grappes RAID, ce qui ajoute un nouveau lot de difficultés :

  • L’information permettant d’émettre la commande TRIM est disponible au niveau du système de fichier uniquement; à ce jour seuls certains systèmes de fichiers expérimentaux dédiés à l’utilisation sur SSD la supportent. On évitera de mettre des données critiques sur un système de fichier expérimental…

  • dès l’instant où le système de fichier repose sur une couche d’abstraction comme LVM ou un RAID logiciel, il faut implémenter des mécanismes permettant :

    • au système de fichier d’indiquer au gestionnaire de volume sous-jacent qu’il implémente la commande TRIM;
    • au gestionnaire de volume d’indiquer au système de fichier hôte que le(s) périphériques sous-jacents supportent la commande TRIM;
    • enfin et c’est le plus complexe, implémenter dans les gestionnaires de volume les mécanismes permettant la translation des adresses virtuelles de blocs du volume logique en blocs physiques sur lesquels appliquer la commande TRIM.
  • de plus, si l’on utilise un contrôleur RAID matériel, il faut également implémenter une norme générale et des méthodes au niveau de chaque pilote de périphérique concerné pour faire de même, c’est à dire indiquer à la couche d’abstraction de niveau bloc que les périphériques blocs sous-jacents supportent le TRIM, d’autre part transmettre les commandes TRIM de façon correcte en faisant les translations d’adresses nécessaires.

On peut donc conclure avec une certaine confiance que nous sommes encore assez loin de pouvoir profiter de la commande TRIM dans les systèmes d’entreprise…

Le SATA 3

Le SATA-3 est la nouvelle norme SATA 6 Gigabits par seconde, qui doit permettre de tirer le meilleur parti des disques SSD. En effet, les 3 Gb/s du SATA-2 permettent de faire transiter au grand maximum 384 Mo/s; or certains SSD peuvent déjà faire mieux. De plus cette nouvelle norme intègre le dernier jeu de commande ATA, dont la fameuse “TRIM”.

Formidable, passons vite au SATA-3!

Petit problème, aucun disque n’existe actuellement à cette norme. Celle-ci a fait son apparition dans le domaine grand public très récemment sur quelques cartes-mères et n’est que très rarement disponible, et il faudra patienter avant qu’il existe des solutions professionnelles (contrôleurs RAID, disques) la supportant.

Inutile d’attendre!

Heureusement, la conclusion générale est malgré tout positive! En effet, les disques SSD ont déjà un immense avantage sur les disques durs ordinaires : leur temps d’accès fabuleusement réduit. Ceci constitue la véritable révolution et le principal attrait du SSD dans le monde de l’entreprise, et on, peut en profiter sans TRIM, sans “garbage collector” et sans SATA-3. Une grappe RAID de quelques disques SSD peut en effet soutenir plusieurs dizaines de milliers d’opérations par seconde, c’est à dire la performance de quelques centaines de disques SAS hors de prix. C’est d’ores et déjà une révolution pour toutes les applications transactionnelles, et nul besoin d’attendre pour en tirer parti! Qui ne rêve de remplacer une pleine armoire de disques en SAN par un simple serveur de 1 ou 2U de rack? C’est déjà une réalité.

Quelques liens :

posté à: 18:04 permalink