Optimisation d’un script SHELL

 

Nous avons un script shell. Celui-ci fonctionne en deux étapes. La première étape dure une nuit. La deuxième étape dure elle aussi toute une nuit. Cependant, ce processus doit être exécuté pour 60 serveurs. La durée totale théorique est donc de 120 jours!

La première étape peut être parallélisée, sur les 60 serveurs en même temps. La première étape peut donc avoir une durée d’une nuit si on lance le processus sur les 60 serveurs en parallèle. La deuxième étape ne peut être parallélisée car elle doit être exécutée sur un seul et unique serveur et elle génère 60 résultats différents (un par serveur source, dépendant du résultat de l’étape 1 des serveurs sources). La 2e étape a donc une durée incompressible de 60 nuits.

Il faut donc au moins 61 nuits (1 + 60) pour exécuter l’intégralité du processus. Trop long. Trop complexe. Trop peu sûr. Comment optimiser cela?

Edit : précisions apportées suite au commentaire de « bob morane », merci à lui!

Continuer la lecture de Optimisation d’un script SHELL

Optimiser la connexion SSH à des serveurs distants

(Image « En plein taff.. » sous licence CC-BY-2.0 par  Thomassin Mickaël)

Le télétravail est une belle invention. Vous pouvez travailler de chez vous, commencer plus tôt et terminer plus tard tout en étant moins fatigué. Vous disposez d’une certaine souplesse, après vous être mis d’accord avec votre responsable, pour vous absenter une petite heure pour aller conduite la voiture au garage par exemple. Vous évitez les transports en commun, très aléatoire en région parisienne, ou les 10 petits kilomètres en voiture à une vitesse moyenne de… 20km/h. Bref, c’est que du bonheur…

Vous lancez votre VPN et vous vous connectez en SSH sur votre poste. De là, vous pouvez lancer des applications graphiques qui s’exécutent sur votre poste au bureau mais s’affichent sur votre ordinateur familial. Vous disposez d’une connexion supra-giga-ultra-méga-très-très-haut débit, grâce à la fibre optique, c’est à dire du 100MBits/s (!!! vivement le supra-giga-ultra-méga-très-très-haut ++ débit) en download et du 50MBits/s en upload. Petit veinard! En dehors du fait qu’on se moque de nous sur le côté très-très-très-haut débit, on constate quand même que ça reste assez… lent. Il y a une certaine latence entre la frappe d’une touche sur le clavier et le moment où le caractère s’affiche. De plus, Firefox et LibreOffice mettent un certain temps à s’afficher lors de nombreux « Alt-Tab ». Ceci est très gênant. D’autant plus gênant lorsqu’on enchaîne deux connexions SSH dans deux tunnels OpenVPN distincts pour lancer un Firefox à l’autre bout afin d’utiliser l’outil d’administration graphique du SAN ou de l’outil de virtualisation. Il peut se passer plusieurs dizaines de secondes entre le changement de fenêtre et le rafraîchissement de l’affichage de cette fenêtre. Comment « accélérer » la connexion SSH? Comment améliorer le ressenti utilisateur?

Continuer la lecture de Optimiser la connexion SSH à des serveurs distants

Statistiques 2014 du blog

 

Un petit retour en arrière peut faire beaucoup de bien. C’est l’occasion de voir ce qui a fonctionné et surtout ce qui n’a pas fonctionné. Riche d’enseignements, ces statistiques de consultation me permettent d’apprendre beaucoup sur moi mais aussi sur les centres d’intérêts des personnes qui visitent le blog. Je peux alors adapter le contenu aux souhaits (supposés!) de mes lecteurs. Bien entendu, m’adapter ne veut pas dire « pervertir mon âme » : je ne vais pas parler d’iPhone quand bien même un millions de personnes me le demanderais :-). Quelles sont les enseignements de cette année 2014?

Continuer la lecture de Statistiques 2014 du blog

Ralentissement incompréhensible lors de l’écriture sur disque

(image « Seagate ST33232A hard disk inner view » par Eric Gaba, Wikimedia Commons user Sting, CC BY-SA 3.0)

Dans la structure dans laquelle je travaille, nous disposons de SAN. Ce sont de « simples » serveurs mais un peu adaptés à nos besoins de stockage :

  • 8 cœurs, pas trop rapides (ce n’est pas nécessaire)
  • entre 8 et 16Go de RAM (on aurait du en prendre beaucoup plus, au prix auquel on l’achète)
  • de 8 disques (pour le plus petit) à 24 disques (pour le plus gros)
  • RAID 1 pour l’OS
  • RAID 5 ou 6 pour les données

L’OS est un Open-E DSS v6. Pourquoi choisir Open-E DSS? Plusieurs raisons :

  1. basé sur GNU/Linux
  2. intègre une interface web relativement correcte
  3. était supporté, à l’époque, par notre revendeur matériel, que nous connaissons bien et qui pouvait nous fournir du conseil si nécessaire
  4. prix abordable
  5. fonctionnalités adaptées à nos besoins

Là n’est pas la question. C’était un très bon choix à l’époque. Va-t’il le rester? C’est une question encore en suspens : par exemple, notre revendeur matériel ne le propose plus.

Puis nous avons commencé à rencontrer des problèmes. De très forts ralentissements lors des écritures sur disque. Nous avons résolu ce problème. Comment? Nous avons le voir.

Continuer la lecture de Ralentissement incompréhensible lors de l’écriture sur disque