{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Les Fondamentaux de ZFS : stockage et performance","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Les
\n
\nCe printemps, nous avons d\u00e9j\u00e0 discut\u00e9 de certains sujets introductifs, tels que comment v\u00e9rifier la vitesse de vos disques<\/a><\/noindex> et ce qu'est le RAID<\/a><\/noindex>. Dans le deuxi\u00e8me, nous avons m\u00eame promis de continuer \u00e0 explorer les performances des diff\u00e9rentes topologies multi-disques dans ZFS. C'est un syst\u00e8me de fichiers de prochaine g\u00e9n\u00e9ration qui est actuellement d\u00e9ploy\u00e9 partout : depuis Apple<\/a><\/noindex> \u00e0 Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nEh bien, aujourd'hui est le jour parfait pour d\u00e9couvrir ZFS, chers lecteurs curieux. Sachez simplement, qu' selon l'estimation modeste du d\u00e9veloppeur OpenZFS Matt Arons, \u00ab c'est vraiment compliqu\u00e9 \u00bb.<\/p>\n

Mais avant d'arriver aux chiffres - et ils viendront, je te le promets - sur toutes les options de la configuration \u00e0 huit disques ZFS, il faut parler de comment comment<\/i> ZFS stocke r\u00e9ellement les donn\u00e9es sur le disque.<\/p>\n

Zpool, vdev et device<\/h1>\n

\n\"Les
\nCe diagramme de pool complet comprend trois vdev auxiliaires, un de chaque type, et quatre pour RAIDz2.<\/i><\/p>\n

\"Les
\nIl n'y a g\u00e9n\u00e9ralement pas de raison de cr\u00e9er un pool \u00e0 partir de types et tailles vdev incompatibles - mais si vous le souhaitez, rien ne vous en emp\u00eache.<\/i><\/p>\n

Pour vraiment comprendre le syst\u00e8me de fichiers ZFS, il faut examiner attentivement sa structure r\u00e9elle. Tout d'abord, ZFS combine les niveaux de gestion des volumes traditionnels et du syst\u00e8me de fichiers. Deuxi\u00e8mement, il utilise un m\u00e9canisme transactionnel de copie \u00e0 l'\u00e9criture. Ces caract\u00e9ristiques signifient que le syst\u00e8me est structurellement tr\u00e8s diff\u00e9rent des syst\u00e8mes de fichiers et des ensembles RAID ordinaires. Le premier ensemble de blocs de construction essentiels \u00e0 comprendre est : le pool de stockage (zpool), le dispositif virtuel (vdev) et le dispositif r\u00e9el (device).<\/p>\n

zpool<\/h3>\n

\nLe pool de stockage zpool est la structure sup\u00e9rieure de ZFS. Chaque pool contient un ou plusieurs dispositifs virtuels. \u00c0 son tour, chacun d'eux contient un ou plusieurs dispositifs r\u00e9els (device). Les pools virtuels sont des blocs autonomes. Un ordinateur physique peut contenir deux ou plusieurs pools distincts, mais chaque pool est enti\u00e8rement ind\u00e9pendant des autres. Les pools ne peuvent pas partager des dispositifs virtuels.<\/p>\n

La redondance de ZFS se trouve au niveau des dispositifs virtuels, et non au niveau des pools. Au niveau des pools, il n'y a absolument aucune redondance - si un dispositif vdev ou un vdev sp\u00e9cial est perdu, alors tout le pool est \u00e9galement perdu.<\/p>\n

Les pools de stockage modernes peuvent survivre \u00e0 la perte de cache ou de journal d'un dispositif virtuel, bien qu'ils puissent perdre une petite quantit\u00e9 de donn\u00e9es en attente si le journal vdev est perdu pendant une coupure de courant ou un \u00e9chec syst\u00e8me.<\/p>\n

Il existe une id\u00e9e re\u00e7ue selon laquelle les \u00ab bandes de donn\u00e9es \u00bb (stripes) ZFS sont \u00e9crites sur l'ensemble du pool. C'est faux. Zpool n'est pas du tout un RAID0, c'est plut\u00f4t un JBOD<\/a><\/noindex> avec un m\u00e9canisme de r\u00e9partition complexe et variable.<\/p>\n

En grande partie, les \u00e9critures sont r\u00e9parties entre les dispositifs virtuels disponibles en fonction de l'espace libre disponible, de sorte qu'en th\u00e9orie, tous seront remplis en m\u00eame temps. Dans les versions ult\u00e9rieures de ZFS, l'utilisation actuelle du vdev est prise en compte ; si un dispositif virtuel est nettement plus charg\u00e9 qu'un autre (par exemple, \u00e0 cause d'une forte charge de lecture), il sera temporairement omis pour l'\u00e9criture, malgr\u00e9 un taux d'espace libre \u00e9lev\u00e9.<\/p>\n

Le m\u00e9canisme de d\u00e9termination de l'utilisation, int\u00e9gr\u00e9 dans les m\u00e9thodes modernes de r\u00e9partition des \u00e9critures ZFS, peut r\u00e9duire la latence et augmenter le d\u00e9bit pendant les p\u00e9riodes de charge exceptionnellement \u00e9lev\u00e9e, mais cela ne fait pas carte blanche<\/i> pour le m\u00e9lange involontaire de disques durs lents et de SSD rapides dans un m\u00eame pool. Un tel pool in\u00e9gal fonctionnera quand m\u00eame \u00e0 la vitesse du p\u00e9riph\u00e9rique le plus lent, c'est-\u00e0-dire comme s'il \u00e9tait enti\u00e8rement constitu\u00e9 de ces dispositifs.<\/p>\n

vdev<\/h3>\n

\nChaque pool de stockage se compose d'un ou plusieurs dispositifs virtuels (device virtuel, vdev). \u00c0 son tour, chaque vdev comprend un ou plusieurs dispositifs physiques. La plupart des dispositifs virtuels sont utilis\u00e9s pour le simple stockage de donn\u00e9es, mais il existe plusieurs classes auxiliaires de vdev, y compris CACHE, LOG et SPECIAL. Chacun de ces types de vdev peut avoir l'une des cinq topologies : dispositif unique (single-device), RAIDz1, RAIDz2, RAIDz3 ou miroir (mirror).<\/p>\n

RAIDz1, RAIDz2 et RAIDz3 sont des variantes sp\u00e9ciales de ce que les anciens appelleraient RAID \u00e0 double parit\u00e9 (diagonale). Les chiffres 1, 2 et 3 se r\u00e9f\u00e8rent au nombre de blocs de parit\u00e9 allou\u00e9s \u00e0 chaque stripe de donn\u00e9es. Au lieu de disques distincts pour assurer la parit\u00e9, les dispositifs RAIDz r\u00e9partissent cette parit\u00e9 de mani\u00e8re semi-\u00e9galitaire sur les disques. Un ensemble RAIDz peut perdre autant de disques qu'il a de blocs de parit\u00e9 ; s'il en perd un de plus, il tombe en panne et emporte avec lui le pool de stockage.<\/p>\n

Dans les dispositifs virtuels miroir (mirror vdev), chaque bloc est stock\u00e9 sur chaque dispositif dans le vdev. Bien que les miroirs doubles (two-wide) soient les plus courants, un miroir peut avoir n'importe quel nombre d'appareils \u2014 dans de grandes installations, pour am\u00e9liorer les performances de lecture et la tol\u00e9rance aux pannes, des miroirs triples sont souvent utilis\u00e9s. Un miroir vdev peut survivre \u00e0 toute panne tant qu'au moins un appareil dans le vdev continue de fonctionner.<\/p>\n

Les vdev simples sont par nature dangereux. Un tel dispositif virtuel ne survivra \u00e0 aucune panne \u2014 et s'il est utilis\u00e9 comme stockage ou vdev sp\u00e9cial, sa panne entra\u00eenera la destruction de l'ensemble du pool. Soyez ici tr\u00e8s, tr\u00e8s prudent.<\/p>\n

Les dispositifs virtuels CACHE, LOG et SPECIAL peuvent \u00eatre cr\u00e9\u00e9s selon n'importe laquelle des topologies mentionn\u00e9es ci-dessus \u2014 mais rappelez-vous que la perte d'un dispositif virtuel SPECIAL signifie la perte du pool, il est donc fortement recommand\u00e9 d'adopter une topologie redondante.<\/p>\n

dispositif<\/h3>\n

\nC'est probablement le terme le plus facile \u00e0 comprendre dans ZFS \u2014 c'est litt\u00e9ralement un dispositif de bloc \u00e0 acc\u00e8s al\u00e9atoire. N'oubliez pas que les dispositifs virtuels se composent d'appareils distincts, et que le pool est constitu\u00e9 de dispositifs virtuels.<\/p>\n

Les disques \u2014 magn\u00e9tiques ou \u00e0 \u00e9tat solide \u2014 sont les dispositifs de bloc les plus courants utilis\u00e9s comme \u00e9l\u00e9ments de construction du vdev. Cependant, tout appareil avec un descripteur dans \/dev convient \u2014 de sorte que des ensembles RAID mat\u00e9riels complets peuvent \u00eatre utilis\u00e9s comme dispositifs distincts.<\/p>\n

Un simple fichier brut est l'un des dispositifs de bloc alternatifs les plus importants \u00e0 partir desquels un vdev peut \u00eatre construit. Les pools de test \u00e0 partir de fichiers \u00e9parpill\u00e9s<\/a><\/noindex>\u00a0sont un moyen tr\u00e8s pratique de v\u00e9rifier les commandes du pool et de voir combien d'espace est disponible dans le pool ou le dispositif virtuel de cette topologie.<\/p>\n

\"Les
\nVous pouvez cr\u00e9er un pool de test \u00e0 partir de fichiers dispers\u00e9s en quelques secondes, mais n'oubliez pas de supprimer ensuite l'ensemble du pool et ses composants.<\/i> <\/p>\n

Supposons que vous souhaitiez configurer un serveur avec huit disques et que vous pr\u00e9voyez d'utiliser des disques de 10 To (~9300 Go) - mais vous n'\u00eates pas s\u00fbr de la topologie qui correspond le mieux \u00e0 vos besoins. Dans l'exemple ci-dessus, nous construisons un pool de test \u00e0 partir de fichiers dispers\u00e9s en quelques secondes - et nous savons maintenant qu'un vdev RAIDz2 compos\u00e9 de huit disques de 10 To offre 50 To d'espace utile.<\/p>\n

Une autre cat\u00e9gorie particuli\u00e8re de dispositifs est l'\u00e9l\u00e9ment SPARE (de secours). Les dispositifs de remplacement \u00e0 chaud, contrairement aux dispositifs normaux, appartiennent \u00e0 l'ensemble du pool et non \u00e0 un seul dispositif virtuel. Si un vdev dans le pool \u00e9choue et qu'un dispositif de secours est connect\u00e9 et disponible, il se joindra automatiquement au vdev d\u00e9faillant.<\/p>\n

Apr\u00e8s avoir \u00e9t\u00e9 connect\u00e9 au vdev d\u00e9faillant, le dispositif de secours commence \u00e0 recevoir des copies ou des reconstructions des donn\u00e9es qui devraient se trouver sur le dispositif manquant. Dans un RAID traditionnel, cela s'appelle la reconstruction, alors que dans ZFS, c'est ce qu'on appelle \u00ab la reconstruction de redondance \u00bb.<\/p>\n

Il est important de noter que les dispositifs de secours ne remplacent pas d\u00e9finitivement les dispositifs d\u00e9faillants. Ils ne constituent qu'un remplacement temporaire pour r\u00e9duire le temps pendant lequel le vdev est d\u00e9grad\u00e9. Une fois que l'administrateur a remplac\u00e9 le dispositif d\u00e9faillant du vdev, la reconstruction de redondance s'effectue sur ce dispositif permanent, et le SPARE se d\u00e9tache du vdev pour revenir \u00e0 un r\u00f4le de secours pour l'ensemble du pool.<\/p>\n

Jeux de donn\u00e9es, blocs et secteurs<\/h1>\n

\nLe prochain ensemble de blocs de construction \u00e0 comprendre dans notre parcours \u00e0 travers ZFS concerne moins le mat\u00e9riel que la mani\u00e8re dont les donn\u00e9es elles-m\u00eames sont organis\u00e9es et stock\u00e9es. Nous allons ici omettre quelques niveaux - comme le metaslab - pour ne pas alourdir les d\u00e9tails tout en pr\u00e9servant la compr\u00e9hension de la structure globale.<\/p>\n

Jeu de donn\u00e9es (dataset)<\/h3>\n

\n\"Les
\nLorsque nous cr\u00e9ons pour la premi\u00e8re fois un jeu de donn\u00e9es, il affiche tout l'espace disponible dans le pool. Nous d\u00e9finissons ensuite une quota et modifions le point de montage. Magie !<\/i> <\/p>\n

\"Les
\nLe Zvol est essentiellement un jeu de donn\u00e9es d\u00e9pourvu de sa couche de syst\u00e8me de fichiers, que nous rempla\u00e7ons ici par un syst\u00e8me de fichiers normal comme ext4.<\/i> <\/p>\n

Un jeu de donn\u00e9es ZFS est environ \u00e9quivalent \u00e0 un syst\u00e8me de fichiers mont\u00e9 standard. Comme un syst\u00e8me de fichiers traditionnel, \u00e0 premi\u00e8re vue, il semble \u00eatre \u00ab simplement un autre dossier \u00bb. Mais tout comme les syst\u00e8mes de fichiers mont\u00e9s ordinaires, chaque jeu de donn\u00e9es ZFS a son propre ensemble de propri\u00e9t\u00e9s fondamentales.<\/p>\n

Tout d'abord, un jeu de donn\u00e9es peut avoir un quota attribu\u00e9. Si vous configurez zfs set quota=100G nom_du_pool\/nom_du_dataset<\/code>, vous ne pourrez pas \u00e9crire dans le dossier mont\u00e9 \/poolname\/datasetname<\/code> plus de 100 Go.<\/p>\n

Avez-vous remarqu\u00e9 la pr\u00e9sence \u2013 et l'absence \u2013 de barres obliques au d\u00e9but de chaque ligne ? Chaque jeu de donn\u00e9es a sa propre place \u00e0 la fois dans la hi\u00e9rarchie ZFS et dans la hi\u00e9rarchie de montage du syst\u00e8me. Dans la hi\u00e9rarchie ZFS, il n'y a pas de barre oblique devant \u2013 vous commencez par le nom du pool, puis le chemin d'un jeu de donn\u00e9es \u00e0 l'autre. Par exemple, pool\/parent\/enfant<\/code> pour un jeu de donn\u00e9es nomm\u00e9 enfant<\/code> sous le jeu de donn\u00e9es parent parent<\/code> dans un pool au nom cr\u00e9atif pool<\/code>.<\/p>\n

Par d\u00e9faut, le point de montage d'un jeu de donn\u00e9es sera \u00e9quivalent \u00e0 son nom dans la hi\u00e9rarchie ZFS, avec une barre oblique au d\u00e9but \u2013 le pool nomm\u00e9 pool<\/code> sera mont\u00e9 comme \/pool<\/code>, le jeu de donn\u00e9es parent<\/code> sera mont\u00e9 dans \/pool\/parent<\/code>, et le jeu de donn\u00e9es enfant enfant<\/code> sera mont\u00e9 dans \/pool\/parent\/child<\/code>. Cependant, le point de montage syst\u00e8me d'un jeu de donn\u00e9es peut \u00eatre modifi\u00e9.<\/p>\n

Si nous sp\u00e9cifions zfs set mountpoint=\/lol pool\/parent\/enfant<\/code>, alors le jeu de donn\u00e9es pool\/parent\/enfant<\/code> sera mont\u00e9 dans le syst\u00e8me comme \/lol<\/code>.<\/p>\n

En plus des jeux de donn\u00e9es, nous devons mentionner les volumes (zvols). Un volume est environ \u00e9quivalent \u00e0 un jeu de donn\u00e9es, sauf qu'il ne contient pas r\u00e9ellement de syst\u00e8me de fichiers - c'est simplement un dispositif bloqu\u00e9. Vous pouvez, par exemple, cr\u00e9er zvol<\/code> avec le nom mypool\/myzvol<\/code>, puis le formater avec un syst\u00e8me de fichiers ext4, et ensuite monter ce syst\u00e8me de fichiers \u2013 maintenant vous avez un syst\u00e8me de fichiers ext4, mais avec le support de toutes les fonctionnalit\u00e9s de s\u00e9curit\u00e9 de ZFS ! Cela peut sembler absurde sur un seul ordinateur, mais cela a beaucoup plus de sens en tant que backend lors de l'exportation d'un dispositif iSCSI.<\/p>\n

Blocs<\/h3>\n

\n\"Les
\nUn fichier est repr\u00e9sent\u00e9 par un ou plusieurs blocs. Chaque bloc est stock\u00e9 sur un dispositif virtuel. La taille du bloc est g\u00e9n\u00e9ralement \u00e9gale au param\u00e8tre recordsize<\/b>, mais peut \u00eatre r\u00e9duite \u00e0 2^ashift<\/b>, si elle contient des m\u00e9tadonn\u00e9es ou un petit fichier.<\/i><\/p>\n

\"Les
\nNous ne plaisantons vraiment pas sur l'\u00e9norme perte de performances si vous d\u00e9finissez un ashift trop petit. vraiment<\/b> Nous ne plaisantons pas sur les \u00e9normes pertes de performance si vous d\u00e9finissez un ashift trop petit.<\/i><\/p>\n

Dans le pool ZFS, toutes les donn\u00e9es, y compris les m\u00e9tadonn\u00e9es, sont stock\u00e9es dans des blocs. La taille maximale d'un bloc pour chaque ensemble de donn\u00e9es est d\u00e9termin\u00e9e par la propri\u00e9t\u00e9 recordsize<\/code> (taille d\u2019enregistrement). La taille d'enregistrement peut varier, mais cela ne changera pas la taille ou la position de n'importe quel bloc qui a d\u00e9j\u00e0 \u00e9t\u00e9 \u00e9crit dans l\u2019ensemble de donn\u00e9es - elle n'agit que pour les nouveaux blocs au fur et \u00e0 mesure qu'ils sont \u00e9crits.<\/p>\n

Si rien d'autre n'est pr\u00e9cis\u00e9, la taille d'enregistrement par d\u00e9faut actuelle est de 128 Ko. C'est une sorte de compromis imparfait, o\u00f9 les performances ne seront pas id\u00e9ales mais pas non plus horribles dans la plupart des cas. Recordsize<\/code> peut \u00eatre fix\u00e9 \u00e0 n'importe quelle valeur entre 4K et 1M (avec des r\u00e9glages suppl\u00e9mentaires recordsize<\/code> peut \u00eatre fix\u00e9 \u00e0 des valeurs encore plus \u00e9lev\u00e9es, mais cela n\u2019est g\u00e9n\u00e9ralement pas une bonne id\u00e9e).<\/p>\n

Chaque bloc ne fait r\u00e9f\u00e9rence qu'aux donn\u00e9es d'un seul fichier - vous ne pouvez pas caser deux fichiers diff\u00e9rents dans un m\u00eame bloc. Chaque fichier est constitu\u00e9 d'un ou plusieurs blocs, selon la taille. Si la taille du fichier est inf\u00e9rieure \u00e0 la taille d'enregistrement, il sera enregistr\u00e9 dans un bloc plus petit - par exemple, un bloc avec un fichier de 2 Ko occupera seulement un secteur de 4 Ko sur le disque.<\/p>\n

Les volumes zvol n'ont pas de propri\u00e9t\u00e9 recordsize<\/code>\u00a0- \u00e0 la place, ils ont une propri\u00e9t\u00e9 \u00e9quivalente volblocksize<\/code>.<\/p>\n

Secteurs<\/h3>\n

\nLe dernier, et le plus fondamental des blocs de construction - le secteur. C'est la plus petite unit\u00e9 physique qui peut \u00eatre \u00e9crite ou lue \u00e0 partir du dispositif de base. Pendant des d\u00e9cennies, la plupart des disques utilisaient des secteurs de 512 octets. R\u00e9cemment, la plupart des disques sont configur\u00e9s avec des secteurs de 4 Ko, et certains - en particulier les SSD - utilisent des secteurs de 8 Ko ou m\u00eame plus.<\/p>\n

Dans le syst\u00e8me ZFS, il existe une propri\u00e9t\u00e9 qui permet de d\u00e9finir manuellement la taille du secteur. Cette propri\u00e9t\u00e9 ashift<\/code>. Il est quelque peu d\u00e9routant que ashift soit une puissance de deux. Par exemple, ashift=9<\/code> signifie une taille de secteur de 2^9, soit 512 octets.<\/p>\n

ZFS interroge le syst\u00e8me d'exploitation pour obtenir des d\u00e9tails sur chaque p\u00e9riph\u00e9rique de bloc lorsqu'il est ajout\u00e9 \u00e0 un nouveau vdev, et th\u00e9oriquement \u00e9tablit automatiquement ashift de mani\u00e8re appropri\u00e9e en fonction de ces informations. Malheureusement, de nombreux disques mentent sur leur taille de secteur pour maintenir la compatibilit\u00e9 avec Windows XP (qui \u00e9tait incapable de comprendre les disques avec d'autres tailles de secteurs).<\/p>\n

Cela signifie qu'il est fortement conseill\u00e9 \u00e0 l'administrateur ZFS de conna\u00eetre la v\u00e9ritable taille de secteur de ses dispositifs et de l'\u00e9tablir manuellement. ashift<\/code>. Si un ashift trop petit est configur\u00e9, le nombre d'op\u00e9rations de lecture\/\u00e9criture augmente de mani\u00e8re astronomique. Par exemple, \u00e9crire des \u00ab secteurs \u00bb de 512 octets dans un v\u00e9ritable secteur de 4 Ko n\u00e9cessite d'\u00e9crire le premier \u00ab secteur \u00bb, puis de lire le secteur de 4 Ko, de le modifier avec le second \u00ab secteur \u00bb de 512 octets, de l'\u00e9crire \u00e0 nouveau dans un nouveau secteur de 4 Ko, et ainsi de suite pour chaque \u00e9criture.<\/p>\n

Dans le monde r\u00e9el, cette p\u00e9nalit\u00e9 impacte les disques SSD Samsung EVO, pour lesquels doit \u00eatre appliqu\u00e9 ashift=13<\/code>, mais ces SSD mentent sur leur taille de secteur, c'est pourquoi par d\u00e9faut, il est configur\u00e9 ashift=9<\/code>. Si un administrateur syst\u00e8me exp\u00e9riment\u00e9 ne modifie pas ce param\u00e8tre, alors ce SSD fonctionne plus lentement<\/i> comme un HDD magn\u00e9tique classique.<\/p>\n

En revanche, pour une taille trop grande, ashift<\/code> il n'y a pratiquement aucune p\u00e9nalit\u00e9. Il n'y a pas de r\u00e9elle diminution de performance, et l'augmentation de l'espace inutilis\u00e9 est n\u00e9gligeable (ou \u00e9gale \u00e0 z\u00e9ro lorsqu'une compression est activ\u00e9e). Par cons\u00e9quent, nous recommandons vivement m\u00eame aux disques qui utilisent r\u00e9ellement des secteurs de 512 octets de d\u00e9finir ashift=12<\/code> ou m\u00eame ashift=13<\/code>, afin de se projeter sereinement dans l'avenir.<\/p>\n

La propri\u00e9t\u00e9 ashift<\/code> est \u00e9tabli pour chaque dispositif virtuel vdev, et non pour le pool<\/i>, comme beaucoup le pensent \u00e0 tort \u2014 et il ne peut pas \u00eatre modifi\u00e9 apr\u00e8s son installation. Si vous le modifiez accidentellement ashift<\/code> lors de l'ajout d'un nouveau vdev au pool, vous avez irr\u00e9m\u00e9diablement contamin\u00e9 ce pool avec un dispositif \u00e0 faible performance et, en g\u00e9n\u00e9ral, il n'y a pas d'autre solution que de d\u00e9truire le pool et de recommencer tout depuis le d\u00e9but. M\u00eame la suppression du vdev ne sauvera pas de la mauvaise configuration. ashift<\/code>!<\/p>\n

Le m\u00e9canisme de copie \u00e0 l'\u00e9criture<\/h3>\n

\n\"Les
\nSi un syst\u00e8me de fichiers classique doit r\u00e9\u00e9crire des donn\u00e9es, il modifie chaque bloc l\u00e0 o\u00f9 il se trouve.<\/i><\/p>\n

\"Les
\nLe syst\u00e8me de fichiers avec copie \u00e0 l'\u00e9criture enregistre une nouvelle version du bloc, puis d\u00e9bloque l'ancienne version.<\/i><\/p>\n

\"Les
\nDe mani\u00e8re abstraite, si l'on ignore l'emplacement physique r\u00e9el des blocs, notre \u00ab com\u00e8te de donn\u00e9es \u00bb se simplifie en un \u00ab ver de donn\u00e9es \u00bb qui se d\u00e9place de gauche \u00e0 droite sur la carte de l'espace disponible.<\/i><\/p>\n

\"Les
\nNous pouvons maintenant avoir une bonne id\u00e9e de la fa\u00e7on dont fonctionnent les instantan\u00e9s de copie \u00e0 l'\u00e9criture \u2014 chaque bloc peut appartenir \u00e0 plusieurs instantan\u00e9s et sera conserv\u00e9 tant que tous les instantan\u00e9s associ\u00e9s ne seront pas d\u00e9truits.<\/i><\/p>\n

Le m\u00e9canisme de copie \u00e0 l'\u00e9criture (Copy on Write, CoW) est la base fondamentale de ce qui rend ZFS si incroyable comme syst\u00e8me. Le concept principal est simple : si vous demandez \u00e0 un syst\u00e8me de fichiers traditionnel de modifier un fichier, il fera exactement ce que vous avez demand\u00e9. Si vous demandez \u00e0 un syst\u00e8me de fichiers avec copie \u00e0 l'\u00e9criture de faire la m\u00eame chose, il va dire \u00ab d'accord \u00bb \u2014 mais il mentira.<\/p>\n

Au lieu de cela, le syst\u00e8me de fichiers avec copie \u00e0 l'\u00e9criture enregistre une nouvelle version du bloc modifi\u00e9, puis met \u00e0 jour les m\u00e9tadonn\u00e9es du fichier pour rompre le lien avec l'ancien bloc et \u00e9tablir un lien avec le nouveau bloc que vous venez d'enregistrer.<\/p>\n

La d\u00e9connexion de l'ancien bloc et la liaison du nouveau se fait en une seule op\u00e9ration, de sorte qu'elle ne peut pas \u00eatre interrompue \u2014 si vous coupez l'alimentation apr\u00e8s que cela se soit produit, vous avez une nouvelle version du fichier, et si vous coupez l'alimentation plus t\u00f4t, vous avez l'ancienne version. Dans tous les cas, il n'y aura pas de conflits dans le syst\u00e8me de fichiers.<\/p>\n

La copie \u00e0 l'\u00e9criture dans ZFS se produit non seulement au niveau du syst\u00e8me de fichiers, mais aussi au niveau de la gestion des disques. Cela signifie que ZFS n'est pas sujet \u00e0 l'effet de trou d'\u00e9criture (trou dans RAID<\/a><\/noindex>) \u2014 un ph\u00e9nom\u00e8ne o\u00f9 une tranche a seulement \u00e9t\u00e9 partiellement enregistr\u00e9e avant un crash du syst\u00e8me, entra\u00eenant des dommages au tableau apr\u00e8s le red\u00e9marrage. Ici, la tranche s'\u00e9crit de mani\u00e8re atomique, vdev est toujours coh\u00e9rent, et Bob est ton oncle.<\/a><\/noindex>.<\/p>\n

ZIL : journal des intentions de ZFS.<\/h3>\n

\n\"Les
\nLe syst\u00e8me ZFS g\u00e8re les \u00e9critures synchrones de mani\u00e8re particuli\u00e8re \u2014 il les sauvegarde temporairement mais imm\u00e9diatement dans le ZIL, avant de les enregistrer de mani\u00e8re permanente avec les \u00e9critures asynchrones.<\/i><\/p>\n

\"Les
\nEn g\u00e9n\u00e9ral, les donn\u00e9es enregistr\u00e9es dans le ZIL ne sont jamais lues \u00e0 nouveau. Mais cela est possible apr\u00e8s un crash du syst\u00e8me.<\/i><\/p>\n

\"Les
\nSLOG, ou dispositif LOG secondaire, est simplement un vdev sp\u00e9cial \u2014 et de pr\u00e9f\u00e9rence tr\u00e8s rapide \u2014 o\u00f9 le ZIL peut \u00eatre stock\u00e9 s\u00e9par\u00e9ment du stockage principal.<\/i><\/p>\n

\"Les
\nApr\u00e8s une panne, toutes les donn\u00e9es non enregistr\u00e9es dans le ZIL sont reproduites \u2014 dans ce cas, le ZIL se trouve sur SLOG, donc elles sont reproduites exactement \u00e0 partir de l\u00e0.<\/i><\/p>\n

Il existe deux cat\u00e9gories principales d'op\u00e9rations d'\u00e9criture \u2014 synchrones (sync) et asynchrones (async). Pour la plupart des charges de travail, la grande majorit\u00e9 des op\u00e9rations d'\u00e9criture sont asynchrones \u2014 le syst\u00e8me de fichiers permet de les agr\u00e9ger et de les renvoyer par paquets, r\u00e9duisant la fragmentation et augmentant consid\u00e9rablement la bande passante.<\/p>\n

Les \u00e9critures synchrones sont tout autre chose. Lorsque l'application demande une \u00e9criture synchrone, elle dit au syst\u00e8me de fichiers : \u00ab Tu dois l'enregistrer dans la m\u00e9moire non volatile. en ce moment<\/i>, et tant que ce n'est pas fait, je ne peux rien faire d'autre. \u00bb Par cons\u00e9quent, les \u00e9critures synchrones doivent \u00eatre imm\u00e9diatement enregistr\u00e9es sur le disque \u2014 et si cela augmente la fragmentation ou r\u00e9duit la bande passante, tant pis.<\/p>\n

ZFS g\u00e8re les \u00e9critures synchrones diff\u00e9remment des syst\u00e8mes de fichiers traditionnels \u2014 au lieu de les injecter imm\u00e9diatement dans le stockage standard, ZFS les enregistre dans une zone de stockage sp\u00e9ciale appel\u00e9e journal d'intentions ZFS \u2014 ZFS Intent Log, ou ZIL. L'astuce est que ces \u00e9critures \u00e9galement<\/i> restent en m\u00e9moire, agr\u00e9geant ensemble les requ\u00eates d'\u00e9criture asynchrones normales, pour \u00eatre ensuite vid\u00e9es dans le stockage comme des TXG (groupes de transactions, Transaction Groups) tout \u00e0 fait normaux.<\/p>\n

Dans un fonctionnement normal, le ZIL est \u00e9crit et jamais relu. Lorsque, apr\u00e8s quelques instants, les \u00e9critures du ZIL sont enregistr\u00e9es dans le stockage principal sous forme de TXG normales depuis la m\u00e9moire vive, elles sont d\u00e9tach\u00e9es du ZIL. La seule fois o\u00f9 quelque chose est lu dans le ZIL, c'est lors de l'importation du pool.<\/p>\n

Si une d\u00e9faillance de ZFS se produit \u2014 d\u00e9faillance du syst\u00e8me d'exploitation ou coupure de courant \u2014 alors que des donn\u00e9es sont pr\u00e9sentes dans le ZIL, ces donn\u00e9es seront lues lors de la prochaine importation du pool (par exemple, lors du red\u00e9marrage d'un syst\u00e8me apr\u00e8s une panne). Tout ce qui se trouve dans le ZIL sera lu, agr\u00e9g\u00e9 en groupes TXG, enregistr\u00e9 dans le stockage principal, puis d\u00e9tach\u00e9 du ZIL au cours du processus d'importation.<\/p>\n

L'une des classes auxiliaires de vdev s'appelle LOG ou SLOG, un dispositif secondaire LOG. Son unique t\u00e2che est de fournir au pool un vdev s\u00e9par\u00e9 et, de pr\u00e9f\u00e9rence, beaucoup plus rapide, avec une tr\u00e8s haute r\u00e9sistance \u00e0 l'\u00e9criture, pour stocker le ZIL, au lieu de stocker le ZIL sur le vdev principal. Le ZIL lui-m\u00eame se comporte de la m\u00eame mani\u00e8re, quelle que soit sa localisation de stockage, mais si le vdev avec LOG pr\u00e9sente une tr\u00e8s haute performance d'\u00e9criture, les \u00e9critures synchrones se produiront plus rapidement.<\/p>\n

Ajouter un vdev avec LOG au pool ne peut en aucun cas am\u00e9liorer<\/b> la performance des \u00e9critures asynchrones \u2013 m\u00eame si vous forcez toutes les \u00e9critures dans le ZIL avec zfs set sync=always<\/code>, elles resteront toutefois li\u00e9es au stockage principal dans le TXG de la m\u00eame mani\u00e8re et au m\u00eame rythme que sans journal. La seule am\u00e9lioration directe des performances est le d\u00e9lai des \u00e9critures synchrones (puisqu'une vitesse de journal plus \u00e9lev\u00e9e acc\u00e9l\u00e8re l'ex\u00e9cution des op\u00e9rations. sync<\/code>).<\/p>\n

Cependant, dans un environnement qui n\u00e9cessite d\u00e9j\u00e0 un grand nombre d'\u00e9critures synchrones, un vdev LOG peut indirectement acc\u00e9l\u00e9rer l'\u00e9criture asynchrone et la lecture sans cache. Le d\u00e9chargement des \u00e9critures ZIL sur un vdev LOG distinct signifie moins de concurrence pour les IOPS dans le stockage primaire, ce qui am\u00e9liore dans une certaine mesure la performance de toutes les op\u00e9rations de lecture et d'\u00e9criture.<\/p>\n

Snapshots<\/h3>\n

\nLe m\u00e9canisme de Copy-on-Write est \u00e9galement une base n\u00e9cessaire pour les snapshots atomiques de ZFS et la r\u00e9plication asynchrone incr\u00e9mentielle. Dans un syst\u00e8me de fichiers actif, il existe un arbre de pointeurs marquant toutes les \u00e9critures avec les donn\u00e9es actuelles \u2013 lorsque vous faites un snapshot, vous faites simplement une copie de cet arbre de pointeurs.<\/p>\n

Lorsqu'une \u00e9criture est r\u00e9\u00e9crite dans un syst\u00e8me de fichiers actif, ZFS \u00e9crit d'abord une nouvelle version du bloc dans l'espace inutilis\u00e9. Il d\u00e9tache ensuite l'ancienne version du bloc du syst\u00e8me de fichiers actuel. Mais si un snapshot fait r\u00e9f\u00e9rence \u00e0 l'ancien bloc, il reste inchang\u00e9. L'ancien bloc ne sera en fait pas r\u00e9cup\u00e9r\u00e9 comme espace libre tant que tous les snapshots faisant r\u00e9f\u00e9rence \u00e0 ce bloc n'auront pas \u00e9t\u00e9 d\u00e9truits !<\/p>\n

R\u00e9plique<\/h3>\n

\n\"Les
\nMa biblioth\u00e8que Steam en 2015 occupait 158 GiB et comprenait 126 927 fichiers. C'est assez proche de la situation optimale pour rsync \u2013 la r\u00e9plication ZFS sur le r\u00e9seau \u00e9tait \u00ab seulement \u00bb 750 % plus rapide.<\/i><\/p>\n

\"Les
\nDans le m\u00eame r\u00e9seau, la r\u00e9plication d'un fichier image de machine virtuelle Windows 7 de 40 Gio est une toute autre histoire. La r\u00e9plication ZFS est 289 fois plus rapide que rsync, ou \u00ab seulement \u00bb 161 fois plus rapide si vous \u00eates suffisamment comp\u00e9tent pour invoquer rsync avec l'option \u2014inplace.<\/i><\/p>\n

\"Les
\nLorsque l'image de la machine virtuelle est mise \u00e0 l'\u00e9chelle, les probl\u00e8mes de rsync se multiplient avec elle. Une taille de 1,9 To n'est pas si grande pour une image de machine virtuelle moderne, mais elle est assez encombrante pour que la r\u00e9plication ZFS soit 1148 fois plus rapide que rsync, m\u00eame avec l'argument rsync \u2014inplace.<\/i><\/p>\n

Une fois que vous comprendrez comment fonctionnent les instantan\u00e9s, il ne sera pas difficile de saisir l'essence de la r\u00e9plication. Puisque l'instantan\u00e9 est simplement un arbre de pointeurs sur des enregistrements, il en d\u00e9coule que lorsque nous faisons un zfs send<\/code> d'un instantan\u00e9, nous envoyons \u00e0 la fois cet arbre et tous les enregistrements associ\u00e9s. Lorsque nous transf\u00e9rons ce zfs send<\/code> dans zfs receive<\/code> vers l'objet cible, il enregistre \u00e0 la fois le contenu r\u00e9el des blocs et l'arbre de pointeurs qui pointent vers ces blocs dans le jeu de donn\u00e9es cible.<\/p>\n

Les choses deviennent encore plus int\u00e9ressantes avec le deuxi\u00e8me zfs send<\/code>. Maintenant, nous avons deux syst\u00e8mes, chacun contenant poolname\/datasetname@1<\/code>, et vous prenez un nouvel instantan\u00e9 poolname\/datasetname@2<\/code>. Ainsi, dans le pool source, vous avez datasetname@1<\/code> et datasetname@2<\/code>, tandis que dans le pool cible, il y a pour l'instant seulement le premier instantan\u00e9. datasetname@1<\/code>.<\/p>\n

Puisque nous avons un instantan\u00e9 commun entre la source et la cible, nous pouvons faire datasetname@1<\/code>incr\u00e9mental par-dessus. Lorsque nous disons au syst\u00e8me<\/i> zfs send<\/code> zfs send -i poolname\/datasetname@1 poolname\/datasetname@2 , il compare les deux arbres de pointeurs. Tous les pointeurs qui existent uniquement dans<\/code>, font \u00e9videmment r\u00e9f\u00e9rence \u00e0 de nouveaux blocs, donc nous aurons besoin du contenu de ces blocs. @2<\/code>Sur le syst\u00e8me distant, le traitement incr\u00e9mental<\/p>\n

est tout aussi simple. D'abord, nous \u00e9crivons tous les nouveaux enregistrements inclus dans le flux send<\/code> , puis nous ajoutons les pointeurs vers ces blocs. Voil\u00e0, nous avons send<\/code>dans le nouveau syst\u00e8me! @2<\/code> La r\u00e9plication incr\u00e9mentale asynchrone ZFS est une \u00e9norme am\u00e9lioration par rapport aux m\u00e9thodes ant\u00e9rieures qui ne reposaient pas sur des instantan\u00e9s, comme rsync. Dans les deux cas, seules les donn\u00e9es modifi\u00e9es sont transf\u00e9r\u00e9es, mais rsync doit d'abord<\/p>\n

lire toutes les donn\u00e9es des deux c\u00f4t\u00e9s pour v\u00e9rifier la somme et la comparer. \u00c0 l'inverse, la r\u00e9plication ZFS ne lit rien d'autre que les arbres de pointeurs, et tout bloc qui n'est pas pr\u00e9sent\u00e9 dans l'instantan\u00e9 commun. lire<\/i> Depuis le disque, toutes les donn\u00e9es des deux c\u00f4t\u00e9s sont v\u00e9rifi\u00e9es pour comparer les sommes. Contrairement \u00e0 cela, la r\u00e9plication ZFS ne lit rien d'autre que les arbres de pointeurs \u2014 et tous les blocs qui ne sont pas repr\u00e9sent\u00e9s dans le snapshot commun.<\/p>\n

Compression int\u00e9gr\u00e9e<\/h3>\n

\nLe m\u00e9canisme de copie \u00e0 l'\u00e9criture simplifie \u00e9galement le syst\u00e8me de compression int\u00e9gr\u00e9e. Dans un syst\u00e8me de fichiers traditionnel, la compression pose des probl\u00e8mes : l'ancienne version et la nouvelle version des donn\u00e9es modifi\u00e9es se trouvent dans le m\u00eame espace.<\/p>\n

Si l'on consid\u00e8re un fragment de donn\u00e9es au milieu d'un fichier, qui commence sa vie comme un m\u00e9gaoctet de z\u00e9ros \u00e0 partir de 0x00000000 et ainsi de suite, il est tr\u00e8s facile de le compresser en un seul secteur sur le disque. Mais que se passera-t-il si nous rempla\u00e7ons ce m\u00e9gaoctet de z\u00e9ros par un m\u00e9gaoctet de donn\u00e9es non compressibles, telles que JPEG ou un bruit pseudo-al\u00e9atoire ? \u00c9tonnamment, ce m\u00e9gaoctet de donn\u00e9es n\u00e9cessitera non pas un, mais 256 secteurs de 4 Ko, alors qu'\u00e0 cet endroit, un seul secteur est r\u00e9serv\u00e9 sur le disque.<\/p>\n

ZFS n'a pas ce probl\u00e8me, car les enregistrements modifi\u00e9s sont toujours \u00e9crits dans l'espace inutilis\u00e9 : le bloc d'origine occupe seulement un secteur de 4 Ko, et le nouvel enregistrement prendra 256, mais ce n'est pas un probl\u00e8me : le fragment r\u00e9cemment modifi\u00e9 du \"milieu\" du fichier serait \u00e9crit dans l'espace inutilis\u00e9, peu importe s'il a chang\u00e9 de taille ou non, donc pour ZFS, c'est une situation tout \u00e0 fait normale.<\/p>\n

La compression int\u00e9gr\u00e9e de ZFS est d\u00e9sactiv\u00e9e par d\u00e9faut, et le syst\u00e8me propose des algorithmes modulaires \u2014 actuellement, parmi eux LZ4, gzip (1-9), LZJB et ZLE.<\/p>\n

Si un fichier est suffisamment grand et n\u00e9cessite plusieurs blocs, alors toutes les entr\u00e9es avec ce fichier auront une taille recordsize<\/code>\u00a0- y compris la derni\u00e8re entr\u00e9e, dont la majeure partie peut s'av\u00e9rer espace inutilis\u00e9<\/a><\/noindex>.<\/p>\n