Impossible de mettre les machines virtuel à l’heure indépendamment de votre dom0 ?
Le serveur physique qui héberge votre machine virtuel n’est pas à l’heure ?
Le serveur domO qui héberge votre DomU est au antipode ou au USA et vous souhaitez avoir l’heure française ?

Ajouter :

xen.independent_wallclock = 1

au fichier /etc/sysctl.conf. Puis lancer la commande suivante

sysctl -p

Reconfigurer la zone de fuseau horaire en choisissant Europe / Paris

dpkg-reconfigure tzdata

Relancer ntpdate

ntpdate fr.pool.ntp.org

Et voila

 

Suite à mes articles sur la configuration eZ publish pour l’utilisation des caches web, sur l’optimisation des reverse proxy squid j’ai tenté de faire la démonstration de l’intérêt de l’ optimisation web cache et des performance des reverses proxys. Je vais apporter quelques preuve de plus dans cet article.

Tenir les versions des logiciels à jours

L’optimisation de ces web cache et la performance des reverses proxys passe tout simplement pas la mise à jour régulière du système et des logiciels. Dans l’exemple ci dessous le gains de performance est flagrant entre une configuration Debian Sarge avec Squid 2.5 et une configuration Debian Etch avec Squid 2.6. Au mois d’octobre 2008 le taux d’utilisation du cpu par le système à chuté, un goulot d’étranglement à été supprimé.

Squid de Sarge a Etch

Soigner la configuration eZ et apache pour squid

Suite à la mort de Michael Jackson Gala.fr et principalement Voici.fr ont connu un très fort pic de charge. Durant cette épisode d’audience intense nous avons poussé en production différente optimisation que nous avions précédemment préparé. Ces optimisations porte sur la configuration de eZ Publish 4 et de Apache pour l’utilisation des caches web. L’effet principale étant obtenue en allongeant le temps de rétentions des images et en instaurant la compression pour les fichiers css et javascript.

Squid Modif conf

Affiner la configuration système des serveurs squid

Une configuration optimum des squid passe également par une adaptation du système à leur mission de reverse proxy tel que nous l’avons réalisé récemment. Le résultat est la et guère discutable pour un charge CPU légèrement supérieur nous desservons plus de client et stockons plus d’objet ce qui conduit à une plus faible sollicitation des frontaux.

Squid.Cpu.Utilisation.png
Squid.Number.Of.Client.png
Squid.Nombre.Objet.Cache.png

 

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.

 

Vous souhaiter utiliser un système Debian mixte qui combinerais des paquets Stable / Oldstable ou Stable / Testing. ? Personnellement je souhaitais installer une version récente de Fail2ban sur un serveur tournant avec une Debian Etch[1]. Pour des raisons de maintenance pas question de faire une installation depuis les sources. J’ai donc souhaité installer le paquet Fail2ban de Debian Lenny [2] sur cette Debian Etch.

APT::Default-Release

Pour ceci il est nécessaire de configurer Apt pour définir votre version principale de Debian. Ceci passe par l’ajout d’un paramètre dans l’arborescence de configuration de APT.

Créé un fichier 01Default-Release. Préfix en 01 pour qu’il soit charger dans les premiers

vi etc/apt] cd apt.conf.d/01Default-Release

Ajouter l’instruction suivante dans le fichier 01Default-Release pour que la version principale de Debian reste en Oldstable / Etch

APT::Default-Release "oldstable";

Dans la branche /etc/apt/apt.conf.d/ vous avez maintenant les fichiers suivant

[root@dweb2 /etc/apt] cd apt.conf.d/ [root@dweb2 /etc/apt/apt.conf.d] ls -l total 16 -rw-r--r-- 1 root root  40 2007-04-10 11:45 00trustcdrom -rw-r--r-- 1 root root  34 2009-09-16 11:25 01Default-Release -rw-r--r-- 1 root root 182 2009-09-16 11:21 70debconf

Reste à modifier le source.list de apt en ajoutant le dépot main de lenny en plus de celuis de etch.

deb ftp://mir1.ovh.net/debian/ etch main deb-src ftp://mir1.ovh.net/debian/ etch main   deb http://security.debian.org/ etch/updates main deb-src http://security.debian.org/ etch/updates main   deb ftp://mir1.ovh.net/debian/ lenny main contrib non-free

Une mise à jour des paquets disponible s’impose avec un apt-get update.

[root@dweb2 /etc/apt] apt-get update Atteint ftp://mir1.ovh.net etch Release.gpg Atteint ftp://mir1.ovh.net lenny Release.gpg Réception de : 1 ftp://mir1.ovh.net etch Release [67,8kB] Réception de : 2 http://security.debian.org etch/updates Release.gpg [835B] Atteint http://security.debian.org etch/updates Release Réception de : 3 ftp://mir1.ovh.net lenny Release [73,6kB] Réception de : 4 ftp://mir1.ovh.net etch/main Packages/DiffIndex Ign ftp://mir1.ovh.net etch/main Packages/DiffIndex Ign http://security.debian.org etch/updates/main Packages/DiffIndex Réception de : 5 ftp://mir1.ovh.net etch/main Sources/DiffIndex Ign ftp://mir1.ovh.net etch/main Sources/DiffIndex Atteint ftp://mir1.ovh.net etch/main Packages Atteint ftp://mir1.ovh.net etch/main Sources Réception de : 6 ftp://mir1.ovh.net lenny/main Packages/DiffIndex Ign ftp://mir1.ovh.net lenny/main Packages/DiffIndex Réception de : 7 ftp://mir1.ovh.net lenny/contrib Packages/DiffIndex Ign ftp://mir1.ovh.net lenny/contrib Packages/DiffIndex Réception de : 8 ftp://mir1.ovh.net lenny/non-free Packages/DiffIndex Ign ftp://mir1.ovh.net lenny/non-free Packages/DiffIndex Atteint ftp://mir1.ovh.net lenny/main Packages Ign http://security.debian.org etch/updates/main Sources/DiffIndex Atteint ftp://mir1.ovh.net lenny/contrib Packages Atteint ftp://mir1.ovh.net lenny/non-free Packages Atteint http://security.debian.org etch/updates/main Packages Atteint http://security.debian.org etch/updates/main Sources 141ko réceptionnés en 0s (1380ko/s) Lecture des listes de paquets... Erreur ! E: Dynamic MMap ran out of room E: Erreur apparue lors du traitement de tcptraceroute (NewVersion2) E: Problem with MergeList /var/lib/apt/lists/mir1.ovh.net_debian_dists_lenny_main_binary-i386_Packages E: Les listes de paquets ou le fichier « status » ne peuvent être analysés ou lus.

APT::Cache-Limit

ZUT !
le message d’erreur final indique un manque d’espace de cache. Nous allons donc configuré apt et luis augmenter son espace de travail. Pour cela on autre comme précédemment un fichier dans l’arborescence de configuration de APT.

vi etc/apt] cd apt.conf.d/02Cache-Limit

On ajoute le paramètre Cache-Limit sur l’exemple suivant

APT::Cache-Limit 20000000;";

La mise à jour des paquets disponible s’impose toujours avec un apt-get update.

[root@dweb2 ~] apt-get update Atteint ftp://mir1.ovh.net etch Release.gpg Atteint ftp://mir1.ovh.net lenny Release.gpg Réception de : 1 ftp://mir1.ovh.net etch Release [67,8kB] Réception de : 2 ftp://mir1.ovh.net lenny Release [73,6kB] Réception de : 3 ftp://mir1.ovh.net etch/main Packages/DiffIndex Ign ftp://mir1.ovh.net etch/main Packages/DiffIndex Réception de : 4 ftp://mir1.ovh.net etch/main Sources/DiffIndex Ign ftp://mir1.ovh.net etch/main Sources/DiffIndex Réception de : 5 ftp://mir1.ovh.net lenny/main Packages/DiffIndex Ign ftp://mir1.ovh.net lenny/main Packages/DiffIndex Réception de : 6 ftp://mir1.ovh.net lenny/contrib Packages/DiffIndex Ign ftp://mir1.ovh.net lenny/contrib Packages/DiffIndex Réception de : 7 ftp://mir1.ovh.net lenny/non-free Packages/DiffIndex Ign ftp://mir1.ovh.net lenny/non-free Packages/DiffIndex Atteint ftp://mir1.ovh.net etch/main Packages Atteint ftp://mir1.ovh.net etch/main Sources Atteint ftp://mir1.ovh.net lenny/main Packages Atteint ftp://mir1.ovh.net lenny/contrib Packages Atteint ftp://mir1.ovh.net lenny/non-free Packages Réception de : 8 http://security.debian.org etch/updates Release.gpg [835B] Atteint http://security.debian.org etch/updates Release Ign http://security.debian.org etch/updates/main Packages/DiffIndex Ign http://security.debian.org etch/updates/main Sources/DiffIndex Atteint http://security.debian.org etch/updates/main Packages Atteint http://security.debian.org etch/updates/main Sources 141ko réceptionnés en 0s (546ko/s) Lecture des listes de paquets... Fait [root@dweb2 ~]

apt-get install -t stable

Par de soucis cette fois
Dans la foulé on installe la version de fail2ban provenant du déport Debian stable avec la commande suivante qui précise par le -t la version à utiliser.

apt-get install -t stable fail2ban

En vrais cela donne

[root@dweb2 /tmp] apt-get install -t stable fail2ban Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Les paquets supplémentaires suivants seront installés :   python-central Paquets suggérés :   python-gamin Les paquets suivants seront mis à jour :   fail2ban python-central 2 mis à jour, 0 nouvellement installés, 0 à enlever et 307 non mis à jour. Il est nécessaire de prendre 127ko dans les archives. Après dépaquetage, 188ko d'espace disque supplémentaires seront utilisés. Souhaitez-vous continuer [O/n] ? o Réception de : 1 ftp://mir1.ovh.net lenny/main python-central 0.6.8 [40,4kB] Réception de : 2 ftp://mir1.ovh.net lenny/main fail2ban 0.8.3-2sid1 [86,2kB] 127ko réceptionnés en 0s (486ko/s) (Lecture de la base de données... 32770 fichiers et répertoires déjà installés.) Préparation du remplacement de python-central 0.5.12 (en utilisant .../python-central_0.6.8_all.deb) ... Dépaquetage de la mise à jour de python-central ... Préparation du remplacement de fail2ban 0.7.5-2etch1 (en utilisant .../fail2ban_0.8.3-2sid1_all.deb) ... Dépaquetage de la mise à jour de fail2ban ... Paramétrage de python-central (0.6.8) ...   Paramétrage de fail2ban (0.8.3-2sid1) ...

Voila tout baigne, fail2ban est installé depuis le depot lenny.

A lire également chez d’autre

Notes

[1] Version Oldstable depuis le 14 février 2009

[2] la version stable courante depuis le 14 février 2009

 

La version de screen présente dans Debian 5.0 Lenny intègre le partage d’écran horizontal et surtout vertical. Un vrai appeau à adminsys avec cette fonction, voici un exemple d’utilisation

  • Lancer screen: # screen
  • Faire partage horizontal : Ctrl a + S (attention à la majuscule)
  • Lancer une commande: htop
  • Passer dans le terminal que nous venons d’ouvrir : Ctr a + Tab
  • Lancer un shell dans ce terminal: Ctrl a + c (attention à la minuscule)
  • Lancer une commande: mtr www.google.fr
  • Faire un partage vertical: Ctr a + | (pipe)
  • Passer dans le terminal que nous venons d’ouvrir : Ctr a + Tab
  • Lancer un shell dans ce terminal: Ctrl a + c (attention à la minuscule)
  • Lancer une commande: tail -f /var/log/syslog
  • Re dimensionner la largeur de ce terminal : Ctr a :resize 60%
  • Passer dans le terminal supérieur : Ctr a + Tab
  • Re dimensionner la hauteur de ce terminal : Ctr a :resize 20%
  • Passer dans le terminal inférieur gauche : Ctr a + Tab
  • Stopper la commande: Ctrl + c
  • Sortir du shell dans ce terminal virtuel: exit
  • Fermer le terminal virtuel: Ctrl + X
  • Passer dans le terminal inférieur : Ctr a + Tab
  • Stopper la commande: Ctrl + c
  • Sortir du shell dans ce terminal virtuel: exit
  • Fermer le terminal virtuel: Ctrl + X

screen.partage.horizontal.vertical.png

Je vous recommande de lire un mémo screen qui regroupe les commandes de base afin de prendre vos marques. Pour les fan de OS X pas de soucis, comme vous pouvez le voir sur ma capture d’écran je suis de votre bord, la solution est chez writequit.org.

© 2012 Karlesnine Suffusion theme by Sayontan Sinha