Archives pour l'étiquette Ext2

Debian Linux : Partitionnement et système de fichier en Web Hosting

Trop bizarre

Par l’interjection trop bizarre Damien attire mon attention sur un aspect souvent oublier de la performance d’une architecture d’hébergement en web hosting: le file system.

twitt.pobel.png

En effet l’installation d’une distribution Linux propose quelque schemas de partitionnement par défaut qui correspond à de grande typologie d’utilisation. L’outil d’installation propose impose également un système de fichier par défaut, en général celui de dernière génération.

Mais dans les architectures de web hosting tout les serveurs ne remplisse pas la même mission (MySQL, Frontal Web, Backoffice, Revers Proxy, etc.) et cette spécialisation est gage de performance. Alors pourquoi la fondation que représente le disque serait uniforme et non pas spécialisé ?

Partitionnement

Le néologisme partitionnement désigne la logique de découpage et d’organisation d’un disque physique en sous secteur spécialisé et / ou dédier. Quel sont les questions, postula et principe de sécurité à prendre en compte ?

  • N’utilise pas le Partitionnement par défaut, c’est un paliatif uniquement
  • Ne fait jamais une partition unique / pour l’intégralité du serveur
  • Une partition distincte préviens le blocage du serveur en cas de saturation de l’espace disque. C’est une sécurité à prendre systématiquement pour éviter le blocage serveur par saturation de l’espace.
  • Un Debian à minima prend 300Mo. Réserve l’espace aux partition de données comme /var ou /home.
  • Garde toujours un espace disque non formaté afin de pouvoir déplacer des partitions et retailler ton disque à la volé.

Exemple.de.partitionnement.png

Personnellement je prend les dispositions suivante

  • /var/log est toujours une partition distincte pour éviter la saturation du disque par oublie d’un mode debug ou une attaque DDOS
  • /tmp est toujours une partition distincte de petite taille, surtout sur les serveurs MySQL (table temporaire). Pour un monitoring de l’utilisation faite de cet espace.
  • Je ne configure très peu de swap et surtout par en proportion. Je considère que swapper c’est être perdant. Le swap est présent juste pour m’alerté quant un serveur l’utilise.
  • Je mélange pas les data avec le binaire, donc /var d’un coter et /usr /bin, /sbin de l’autre.

Système de fichier

Le système de fichier proposé par défaut est en général ext3 ou au moins un système de fichier journalisé. Mais d’autre système de fichier existe ! Quelques réflexions sur le système de fichier optimum.

  • Avez vous besoin d’un système de fichier journalisé qui puisse résisté un crach ou un hard reboot pour la partion ?
  • Avez vous besoin d’un système de fichier avec snapshot pour plus facilement manipulé vos données ?
  • Faite votre propre Benchmark en fonction de l’utilisation spécifique faite du disque par votre serveur, consulté les études de debian-administration.org ou de linuxgazette.net pour vous faire un idée.

ext2.exemple.fstab.png

Personnellement je prend les dispositions suivante

  • J’utilise ext2 dès que possible pour limité les I/O. Dans cette copie écran j’ai directement configuré /etc/fstab pour utilisé ext2 au montage sur une partiton déjà existante en ext3 ceci sans reformaté (parfaitement possible)
  • kathryl abuse d’XFS c’est aussi une solution performante, surtout sur les gros fichiers selon mon expérience.

Montage

L’optimisation du montage des partitions par la commande mount et le fichier de configuration /etc/fstab est source de performance. La encore quelque règle de base.

  • Lire et relire man fstab
  • Lire et relire man mount
  • Choisir les options de montage adéquates pour l’utilisation faite de la partition.

noatime.exemple.png

Personnellement je prend les dispositions suivante

  • Je remplace l’option de montage default par rw,suid,dev,exec,auto,nouser,async
  • J’ajoute noatime et nodiratime pour ne pas enregistrer le time stamp d’accès sur chaque inode. Je gagne un peu en I/O comme cela.
  • Rendre /tmp non exécutable est aussi une bonne idée. Question sécurité c’est tip top je pense.

Performance

Le disque est le sous système de l’ordinateur le plus lent. Chaque fois que vous utilisez le disque dur vous perdez des points dans la course à la rapidité. Apprenez à maitriser les performances matériel.

  • Sas, S-ATA, SSD c’est pas la même chose, connaissez votre matériel
  • Grappe de disque RAID ? RAID 0 et RAID 5 offre le meilleur performance et répartissant les opérations sur plusieurs mécanique en parallèle .

Personnellement je prend les dispositions suivante

  • Je place si possible le système et les données sur des disques distinct. Souvent c’est le système en local et les données sur le SAN / NAS
  • Si je me paye un SSD j’éviterais d’être abruti au point de négliger le choix du file system et des options de montage
  • Avec deux disques pour les données c’est Raid0 pour les performance. Mais pas question d’être négligeant sur les sauvegardes.
  • Avec plus de deux disques c’est Raid5 sans réfléchir.

Voici.fr : Optimiser les performances reverse proxy de SQUID

Une architecture de reverse proxy et après ?

Vous avez configuré votre application pour tirer partie le mieux possible des possibilités offertes par les caches web comme nous l’avons fait dans notre utilisation de eZ Publish pour les sites web du groupe Prisma-Presse.

Mais après cette optimisation ? Kathryl a publié un billet sur l’optimisation des performances de SQUID utilisé en reverse proxy. Il ce base sur notre expérience commune dans la gestion de l’hébergement des sites web du groupe Prisma Presse. Les sites à très forte audience comme Voici.fr, Gala.fr, Femmeactuelle.fr bénéficie des optimisations qu’il présente dans sa documentation.

J’ai souhaité ajouter quelques précisions sur le sujet et expliquer comment vous arrivions à répondre a 92,23% des requêtes HTTP avec nos reverses proxys comme je l’avais annoncé dans un commentaire sur un billet précédent. Kathryl et moi versons parfois dans la bataille d’expert mais c’est par ce jeu de confrontation technique que nous avons trouvé des solutions aux défis qui ce présentaient à nous. Le principal de ces défis relevé est d’avoir trouvé comment soutenir l’audience montante des site du groupe sans la moindre aquisition de matériel depuis un an, mais ceci fera l’objet d’un billet sur le cost killing dans le web hosting.

L’OS : Debian Lenny 64bits

Pourquoi le 64Bits ? Parce que nous recherchons les performance et que c’est l’architecture qui offre la possibilité d’affectation d’un gros volume de mémoire à un même processus. Dans la cas présent nos services squid joues avec plus de 3Go rien que pour le cache mémoire je pense que c’était indispensable.

Gestion de la mémoire RAM avec Squid

La FAQ de squid proxy est très claire au sujet de la mémoire. Plus squid est configuré avec un stockage disque important via la directive cache_dir plus il aura besoin de mémoire pour en ordonné l’utilisation. Mais en outre plus vous allouez d’espace de mémoire pour squid via la directive cache_mem plus squid aura besoin de mémoire vive, en dehors du quota alloué par cette directive, pour ordonner la aussi les objets stocker dans ce cache.

En résumé plus vous allouez de mémoire de cache, en RAM ou sur Disque, plus vous devez prévoir de mémoire vivre à la disposition de l’application.

Kathryl dans son billet propose un rapport de 1 à 4 entre la mémoire cache alloué via la directive cache_mem et la mémoire RAM total disponible. Le rapport n’est que de 1 à 1,3 actuellement en production sur l’étage reverse proxy. Dans tout les cas surveiller bien que la machine n’utilise pas le swap dans le cas contraire les ralentissements arrivent et vous avez tout faux, il faut revoir vos valeurs. Nous avions fait cette erreur d’allouer trop de mémoire via la directive cache_mem et nous avons ralentis nos reverse proxys du fait de l’utilisation du swap.

Taille des objets en cache mémoire

Kathryl avance la question suivante a la quelle je souscris totalement: En quoi est il pertinent d’accepté en mémoire cache RAM des objets volumineux ? Dans le cas des sites qui nous occupe cela n’a pas d’utilité le réglage du backoffice assurant de ne pas avoir des objets trop gros dans le storage de l’application. Dans notre cas nous avons limité la taille des objets présent dans la mémoire vive de cache pour les cantonner au cache disque via la directive maximum_object_size_in_memory. Vous pouvez aussi via la directive maximum_object_size limité en disque également la taille des objets

Si vous diffusez des objets volumineux comme des pdf ou des archives zip il est intéressant d’accepter de relativement gros objets dans votre cache. Dans tout les cas ne pas négligé ces paramètres, il vous permettrons de mettre en évidence la présence de gros objet sur votre site si vous les refuser car vos frontaux web seront sollicité directement ou au contraire vous offrirons la solution pour leur diffusion.

Espace de cache disque

Dans le cas de notre architecture reverse proxy nous avons fait les choix suivant pour l’accueil de l’espace disque alloué avec la directive cache_dir :

  1. Un filesystem dédié
  2. Ext2 pour évité les opérations de journalisation et gagné quelque I/O
  3. Un volume de 15Go pour une occupation de 12Go soit 80%
  4. option noatime dans /etc/fstab

Si vous disposez d’un gros disque SSD je vous invite à l’utiliser dans ce cadre, personnellement je rêve de voir les performances possible. De même si vous avez la possibilité de raid0 sur un paquet de disque rapide ne vous privez par surtout. Je vous recommande la lecture de la documentation squid cache disk io performance enhancements qui vous apportera beaucoup d’information. Le benchmark de FileSystem suivant vous apportera quelque informations. Personnellement je préfère la solution ext2 à tout autre. Attention Kathryl est mono-maniac de XFS mais cela tiens, je pense à ces habitues de feignant consistant à faire de dump pour migré ces données 🙂

Les logs

Comme le souligne Kathryl lorsque l’on fait très forte audience, les logs par leur écriture ralentisse les serveurs (apache ou squid). Personnellement si je le pouvais je les désactiverais complètement et constamment. Dans quelque cas nous avons trouvé avec cette solution la bouffé d’air frais pour re-stabilisé une architecture ou répondre ponctuellement à une surcharge. Mais, bon, c’est mal et juridiquement interdit car il y a une obligation légale de fournir aux autorités sur présentation d’une réquisition judiciaire les ip des internautes visiteurs.

Il vous reste à étudier

Méthode de cache de Squid

Liser les préconisations de Kathryl sur le sujet, il à un préférence pour DISKD. Nous utilisons UFS en production . Je découvre le passage sur les méthode de cache disque de la documentation de Funkywizard qui lui préfère COSS

Connexions

Kathryl est partisans du « lâché moi la jambe ». Les serveurs de cache ne sont pas la pour garder des sockets ouverts trop longtemps. Il préconise de refuser les connections persistantes. C’est un chose que nous n’avons pas testé plus en avant.