Archives pour l'étiquette nfs

Site web média et presse : Le stockage et l’espace disque

Question matutinal

Si je reformule les deux interrogations  du matin je poserais la question suivante : Quel est l’impact financier le plus important du stockage (news et archive) pour un site web de presse ou média. Est-ce l’espace disque pour le stockage lui même ou la bande passante pour exploiter ce qui à été stocké ?

Je n’ai pas le temps ni l’envie de faire des statistiques, des benchmarck ou de compiler des données. Je vais donc donner mon humble avis en me basant sur mes souvenirs de Prisma-Presse, sur mon actualité chez Mondadori et plus largement sur mon expérience.

L’espace disque

L’espace disque brut en 2014 n’est plus un problème. Je parle bien d’espace disque brut, c’est à dire le disque lui même et pas forcément les moyens de l’exploiter.

Sur Amazon Web Service, qui de par sa position de leader donne la température, 13To de disque magnétique de performance moyen coût légèrement moins de 800$ HT par mois. Chez OVH, leader en France, un NAS incluant les moyens de partager l’espace disque et de l’administrer (cif / nfs / etc) c’est 1000€ HT par mois

13To c’est à peu moins d’un tiers de l’espace disque total nécessaire à un groupe presse de la taille de Prisma Presse ou Mondadori pour faire fonctionner l’ensemble des services.

On vois que les coûts d’espace disque brut sans être négligeable ne sont pas insurmontable.

La bande passante

La bande passante en 2014 n’est pas un problème sauf ponctuellement et encore.

Si ont rependre comme référence Amazon Web Service , OVH ou d’autre (ikoula, Oxalid, iliad etc..) vous aurez à votre disposition des gros tuyaux capable de compenser le pire des complexes phalliques du plus minable des machistes. Bref de l’énorme.

Sur Amazon Web Service, sans optimisation des coûts, 10Go de transfert vers l’internet par jour vous coûtera  35$ par mois. C’est un peu près le volume de donnée pour trois sites web féminin majeur français (je ne cite personne)

Ponctuellement, un scoop, un buzz, un événement peux engendrer une surcharge à l’entré du tuyau :

  • Si vous êtes encore dans une infrastructure dédier et cantonné dans un data center en général la couche firewall et / ou répartiteur de charge est taillé pour assurer à 120 ou 130% de consommation courante.  Payé 30% de plus de capacité et ne pas l’utiliser 99% temps est, financièrement, une sécurité suffisamment coûteuse pour la plupart des dirigeants.  Donc, 24h ou 48h par ans, un scoop tombe et engendre un pic d’audience. Malgré le cache http et les CDN vous n’avez pas la qualité de service optimum et ça râle à l’édito. Vous rappeler le prix du service up a 100% quel que soit les conditions, tout le monde tousse et on passe à la question suivante.
  • Et encore si êtes dans un vrai cloud type IaaS (et pas juste de la virtualisation) vous avez la capacité d’être élastique, agile et réactif. Vous augmenterez votre capacité le temps de la tempête médiatique. Cela peux coûter un peu, mais cela dure juste le temps de la vague.

Il est ou le vrai coût du stockage ?

Le vrais coût du stockage est dans le stack applicatif utilisant le stockage, c.a.d votre site web.

Si votre développement ne sais que écrire ou lire dans un répertoire sans la moindre intelligence vous ne pourrez jamais tirer parti des systèmes de stockages qu’invente les acteurs de l’hébergement web, du cloud et des évolutions en général.

Une stack applicatif capable de changer de backend de storage pour passer d’un disque, à un NAS, puis à du AWS S3 cela a un coût bien supérieur au volume de disque ou à la BP brute. C’est du travail d’architecte web et de développeur, du jus de cerveaux qui à un coût. Soit ponctuellement par un grand big bang pour changer de paradigme de stockage, soit en continu.

Une stack applicatif applicative qui n’est pas économe des ressources de stockage. Qui ne prend pas en compte son propre auto-nettoyage. Qui ne vide pas automatiquement la poubelle, ne supprime pas les versions obsolètes. Un stack applicative de ce type va entasser. En dernier lieu plus personne ne maîtrise, personne ne veut prendre le risque de supprimer du contenu et c’est l’explosion du stockage.

Un autre partie, très souvent négligé, c’est les opérations d’exploitation et de sysadmin. Plus votre stockage augmentent et reste monolithique (cf: lire et écrire dans un répertoire)  plus sa manipulation  devient problématique. Déplacement, duplication, backup, restaurations, migration, synchronisation prendrons un temps précieux et tuerons toute réactivité.

La également votre  stack applicatif doit être capable d’adresser les objets stocker de façon répartie et modulaire (sharding, hachage, migration continue etc.), un peu sur disque et beaucoup dans le cloud. Et nous en revenons au jus de cerveaux et au code.

Le stockage ne coûte plus grand chose. Le tuyau de bande passante, moyen d’origine pour utiliser le stockage ne coûte pas non plus beaucoup. Mais le moyen d’utiliser les différents stockages, voir plusieurs en même temps; de passer de l’un l’autre, de façon répartie et modulaire repose sur le code de votre application. Et ça c’est du jus de cerveau qui à un prix.

Autant du stockage brut doit être considéré comme un coût. Un peu comme de l’essence pour une voiture. Autant la création d’une voiture capable d’utiliser indifféremment carburant est un investissement. Même chose pour vos applications.

Voici.fr : Voila un score

Et hop 650 000 pages vue en 24h hier pour le site people. Ceci avec un maximum de 350 requètes seconde sur les trois reverse proxy squid. Ces trois squid étant load balancé tout simplement par LVS. La particularité de pool de reverse proxy squid est dans la configuration. Avant toute interrogation des frontaux ils s’échangent entre eux les pages dont le temps de vie du cache n’est pas écoulé. Et si aucun n’a la pages en cache, un seul d’entre eux vient interroger les frontaux avant de mettre ces congénères à jour. Je ne cache pas qu’il a été nécessaire de modéliser cette architecture à l’échelle 1 avec des instances virtuel xen pour trouver le bon réglage.

Derrière les reverse proxy cinq serveurs apache 1.3 constituent le pool de production php5 et hébergent les instances eZ 4.x. La répartitions entre les frontaux ce faisant pas round robin, le plus faible (Xeon E5310 à 1.60GHz) est monté à 25% d’utilisation de cpu alors que le plus puissant ( Xeon X5355 à 2.66GHz) et monté lui à 15%. Les instances eZ sont en eZFS avec un montage NFS sur un FAS 3070.

Oui avec le 3070 on atteins l’étage lourde de l’architecture. Jusqu’a cette étage les logiciels libres dominaient et assuraient le charge de travail avec une poignée de multi-core et deux brouettes de Ram. Là, obligation de passer par du lourd en effet.

NFS

Le partage de fichier sous unix c’est avant tout NFS, mais comment y faire sur gnu / linux Debian ? Et bien voilà un article de découverte pour les amateurs et à la fois aide mémoire pour les gens expérimentés.

NFS

NFS est un système de fichiers par réseau, qui, en ce qui concerne les caractéristiques importantes, est performant, marche bien, est simple à mettre en oeuvre et le plus important à savoir il crée tout un tas de problèmes de sécurité bien connus des méchants qui veulent obtenir l’accès (lecture, écriture et effacement) à vos fichiers.

la RFC est née

NFS (Network Filesystem Sun) est née avec la RFC 1094 de mars 1989. Comme son nom l’indique Sun en est le créateur. NFS fournit un accès à distance à des fichiers partagés à travers un réseau de façon transparente. NFS a été conçu pour être utilisable quel que soit l’architecture machine, l’OS, l’architecture réseau ou le protocole de transport. NFS s’appuie sur les Remote Procedure Call (RPC) définie dans la RFC 1057.

Quelle utilisation

Connaissant la mauvaise réputation du point de vue de la sécurité de NFS dans quel cas peut-il rendre service à quelqu’un de moyennement paranoïaque ? Personnellement j’ai trois expériences d’utilisation pour vous servir d’exemple.

  1. Pour un petit réseau local de quelques PC afin decentraliser les répertoires personnels sur un serveur et accéder a ceux ci via NFS. Le serveur comportant tout le nécessaire pour la protection des données (raid5, backup sur bande, onduleur) ce qui n’es pas le cas des postes de travail. Le risque lié de « piratage » via NFS étant inférieur au risque de perdre des données pour bien des TPE et PME.
  2. Pour relier des serveurs d’application ou de service à des serveurs de fichiers. Un ou plusieurs serveurs web ( apache / php ) destinés à de la gestion documentaire accédant via NFS aux données stockées sur un ou plusieurs serveurs de fichiers. L’ensemble étant isolé dans un sous réseau et protégé par un firewall ne laissant passer que le https.
  3. Pour une utilisation personnelle entre mon portable et mon serveur de fichier. J’utilise les fichiers hosts.allow et hosts.deny pour expressement interdire toute connection RPC sur le serveur sauf pour le service NFS et encore exclusivement pour ma machine ceci en plus du partage NFS réservé a mon adresse IP.

Gestion des droits

NFS ne gère pas de droit d’accès, il partage des fichiers, il le fait bien mais ne surveille ni ne contrôle rien. La gestion des droits d’accès est le domaine du système, en conséquence NFS se base sur les autorisations données par le noyau. Les fichiers sont exportés par défaut avec un identificateur d’utilisateur (UID] qui est celui que possède le fichier sur la machine serveur. Or il est tout à fait possible que cet identificateur ne corresponde pas au même utilisateur sur toutes les machines clientes. Cela signifie que les utilisateurs des machines clientes peuvent parfaitement avoir accès à des fichiers qui ne leur appartiennent pas sur le serveur et donc les lire, les modifier voire les effacer. Bon, dit comme cela c’est pas encourageant mais une fois cela connu il fait agir en conséquence et en tenir compte, cela devient même un avantage quand il faut organiser la gestion des accès.

NFS fournit plusieurs solutions pour assurer la sécurité sur les systèmes de fichiers exportés.

  1. La première, qui est aussi la plus restrictive, est d’attribuer les fichiers exportés à un utilisateur ne disposant de quasiment aucun droit comme l’utilisateur « nobody », c’est le cas par défaut pour l’utilisateur root.
  2. La deuxième solution est nettement moins sûre. Elle nécessite de lancer le démon « ugidd » sur chaque machine client. Ce démon détermine pour NFS l’identification des utilisateurs du client à partir de leur nom.
  3. La troisième solution est de définir sur le serveur l’association entre les identificateurs des utilisateurs du serveur et les identificateurs du client, et ce pour chaque machine cliente.
  4. Enfin, la dernière solution est d’utiliser les services d’information du réseau NIS (abréviation de l’anglais « Network Information Service »), qui permettent de centraliser la définition des utilisateurs et des mots de passe. Toutes ces techniques peuvent être activées à l’aide d’options fournies dans la liste des options pour chaque machine déclarées dans le fichier de configuration /etc/exports.

Installation coté serveur

Il existe deux paquets debian pour créer un serveur NFS : nfs-user-server et nfs-kernel-server. Chacun a des particularités, des avantages et des inconvénients. J’ai fait le choix de nfs-kernel-server car il y a plus de documentation disponible et aussi parce que nfs-user-server est un paquet orphelin (plus de mainteneur debian) depuis mai 2004.

Commencer par vérifier la présence de nfs-kernel-server avec dpk
dpkg -l | grep nfs-kernel-server

Si ce paquet n’est pas présent installez le. Par le jeux des dépendances le paquet nfs-common et portmap sont également installés :
apt-get install nfs-kernel-server

Avec ces paquets les démons nécessaires sont maintenant installés sur votre système. Si vous souhaitez en savoir plus, les commandes de dpkg suivantes vous donneront le contenu des paquets que vous venez d’installer :
dpkg -L nfs-kernel-server

Alors on trouve une foule de documents dont des scripts d’initialisation que je vous invite à lire afin d’en comprendre le fonctionnement :

/etc/init.d/nfs-common
/etc/init.d/nfs-kernel-server
/etc/init.d/nfs-user-server

Maintenant il est nécessaire de créér le partage des fichiers souhaités en renseignant le fichier /etc/exports. La syntaxe est facile, elle consiste à désignr sur chaque ligne le répertoire à partager et ceux qui auront le droit d’y accéder, par défaut rien n’est partagé ce qui me semble normal. Voici en exemple la syntaxe du fichier /etc/export pour partager un répertoire avec tout le monde sans limitation particulière ni sécurité :
/home/votreid/test

Bon avec un fichier /etc/exports comme cela tout le monde sur votre réseau est capable de monter votre partage, de lire vos fichiers si les droits de ceux ci le permettent. Limitons donc l’accès à ce partage à quelques machines clientes sélectionnées. Pour cela nous avons le choix entre différentes solutions :

Avec le Hostname ou IP. C’est la façon la plus simple de limiter l’accès à une machine à partir du nom machine ou de l’adresse IP. Il est possible d’utiliser des caractères génériques (* ou ? ) pour étendre l’accès à un groupe de machine ou à un domaine comme *.domaine.tld ou PC ???.domaine.tld Un group utilisateur NIS comme @group. Le réseau en spécifiant le netmask comme 192.168.100.0 / 24 ou 192.168.100.0/255.255.255.0

Maintenant il s’agit d’utiliser les bonnes options passées en paramètres pour affiner la sécurité.

insecure Autorise les accès sans authentification, bref danger
unix_rpc Demande l’authentification RPC. La requête vient d’un port réservé (c.a.d inférieur à 1014).
root_squash Interdit aux administrateurs des machines clientes d’avoir tous les droits sur les fichiers partagés par la machine serveur, ceci en l’identifiant comme étant l’utilisateur nobody.
no_root_squash Autorise les administrateurs des machines clientes à avoir tous les droits sur les fichiers partagés par la machine serveur comme s’ ils étaient administrateurs de cette machine.
ro Read only, autorise la lecture seulement
rw Read write, autorise la lecture et l’écriture
link_relative Convertit les liens symboliques absolus (débutant par /) en liens symboliques en ajoutant ../ autant de fois que nécessaire pour aller du répertoire ou est le lien à la racine de la machine serveur. Cela n’a pas d’utilité à moins de partager un disque système entier. C’est l’option par défaut.
link_absolute Laisse les liens symboliques inchangés
map_identity Ceci indique au serveur NFS que la machine cliente utilise les mêmes identifiants utilisateur. C’est l’option par défaut.
map_daemon Option pour indiquer au serveur NFS d’interroger le démon ugidd pour établir une correspondance entre les identifiants utilisateur.
all_squash permet d’exporter tous les fichiers comme appartenant à l’utilisateur
nobody. C’est l’option la plus sûre, mais aussi la plus restrictive.
anonuid et anongid Cette option force un UID et / ou GID précis pour toutes les requêtes. Si le un UID ou GID n’est pas spécifié l’UID de nobody est donnné.
map_daemon permet d’utiliser le démon ugidd, qui doit être lancé sur les machines clientes et accessibles du serveur. L’accès aux répertoires exportés sera refusé si ce démon ne peut être contacté par le serveur NFS. C’est certainement la solution la plus pratique pour un particulier.
map_static=fichier Cette option n’est valable que pour le paquet nfs-user-server, je n’ai donc pas pu la tester. Elle permet théoriquement d’utiliser un fichier de correspondance des identificateurs des utilisateurs du serveur NFS sur les identificateurs des utilisateurs de la machine cliente [1].

Le fichier exports par l’exemple

Prenons en exemple le fichier exports suivant trouvé dans le man :

# sample /etc/exports file
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)

La première ligne donne le partage total de la machine aux machinex clientex master et trusty avec les droits de lecture et d ‘écriture. En outre l’administrateur de trusty a tous les droits sur les fichiers partagés par la machine serveur comme s’ il était administrateur de cette machine. Les deux lignes suivantes montrent l’exemple d’utilisation de caractère générique ( * et ? ) . De plus la troisième ligne comporte les droits d’accès pour un groupe NIS nommé @trusted. Sur la quatrième ligne le partage est configuré pour que chaque requête ait l’UID et GID 150. Enfin la dernière ligne partage le répertoire publique du serveur FTP en lecture seul sans qu’ aucune authentification ne soit nécessaire.

texte - 183 octets
/etc/exports
fichier exports d’exemple

Démarrer le serveur NFS

Maintenant que votre fichier /etc/exports est rédigé demandez à nfs-kernel-server de démarrer :
# /etc/init.d/nfs-kernel-server start Resultat :

Exporting directories for NFS kernel daemon...done.
Starting NFS kernel daemon: nfsd mountdwaiter:#

C’est à ce moment la que les messages d’erreurs devraient vous renseigner sur la syntaxe de votre fichier exports, faites les corrections nécessaires et recommencez.

Et coté client ?

En premier lieu assurez vous que le support NFS est inclus dans le noyau. C’est forcement le cas pour les noyaux fournis durant les installations de woody ou sarge. Le meilleur moyen de le savoir est encore de demander au noyau en personne.


cat /proc/filesystems

Résulta :


nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev futexfs
nodev tmpfs
nodev pipefs
nodev eventpollfs
nodev devpts
ext3
ext2
nodev ramfs
vfat
nodev usbfs
nodev usbdevfs
nodev rpc_pipefs
nodev nfs

La dernière ligne indique que mon noyau a le support NFS inclus. Si cela n’est pas le cas les joies de la compilation vous attendent, mon article sur le sujet peut vous aider.

Maintenant verifiez la présence du démon portmap avec la commande suivante :
dpkg -l | grep portmape

Dans le cas contraire à vous de jouer et de l’installer : apt-get portmap_

En suite il vous faut créér le point de montage
mkdir /mnt/partage_nfs

Modifiez les droits sur le point de montage à votre convenance :
chmod 777 /mnt/partage_nfs

Et maintenant montez le partage :
mount nom-du-server-nfs:/files0 /mnt/partage_nfs/

Cela ne marche pas

  1. Les machines pinguent-elles ?
  2. Les services sont bien démarrés ? Vérifier /etc/init.d/portmap coté client et nfs-server du côté serveur .
  3. Le fichier exports est il correct ?
  4. Vérifier les log dans /var/log/syslog coté client et coté serveur.

Une idée fausse est de penser que le sacrifice d’un poulet lors de la prochaine lune montante puisse changer quelque chose. L’informatique n’est pas de la magie ; si cela ne marche pas c’est que quelqu’un a fait une erreur (ce qui est humain) vous, le programmeur ou le fabriquant de matériel.

Documentation

NFS-HOWTO
www.tldp.org/Diskless-root-NFS-HOWTO
www.tldp.org/Diskless-root-NFS-other-HOWTO
freenix.fr/NFS-HOWTO
fr.tldp.org/NFS-HOWTO
lea-linux.org
developpez.com


[1] L’option map_static permet de définir en général ou pour chaque machine, la correspondance des identificateurs d’utilisateurs. Le fichier fourni en paramètre avec l’option map_static a la syntaxe suivante :

# Exemple de fichier de correspondance d'identificateurs
# Attention spécifier UID ou GID en introduction de chaque ligne
# client serveur
uid 0-99 -
uid 500-1000 1000

Dans cet exemple les utilisateurs ayant un identificateur compris entre 0 et 99 inclus seront associés à l’utilisateur nobody, de même pour les groupes allant de 0 à 49. En revanche, les utilisateurs dont les identificateurs vont de 500 à 1000 sur la machine cliente se voient respectivement considérés comme les utilisateurs d’identificateur 1000 à 1500 par le serveur NFS.