5 votes

Enkay avatar

Déplacer les répertoires /var vers /mnt sur une instance EC2

Demandé el 13 de Décembre, 2012
Quand la question a-t-elle été
1819 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'essaie de travailler sur une configuration standard pour un ensemble d'instances EC2 fonctionnant sous ubuntu 12.04. Ces serveurs seront principalement des serveurs web pour une application Ruby on Rails. Lorsque vous configurez une nouvelle instance de grande taille, vous disposez d'un disque primaire de 8 Go et d'un stockage éphémère de 400 Go monté sur /mnt.

Il me semble logique de déplacer certains répertoires qui ont un potentiel de croissance vers le répertoire /mnt, je pensais notamment à /var/www y /var/log .

Ma question est double :

  1. Est-ce une bonne idée ou y a-t-il des pièges que je ne vois pas ?

  2. Si c'est une bonne idée, comment dois-je procéder pour la configurer ? J'ai la possibilité de configurer de nouvelles instances et de supprimer les anciennes. Je suis préoccupé par la configuration à long terme, mais pas nécessairement par les temps d'arrêt.

Je suis un développeur avec une certaine expérience en matière de devops, mais le montage de disques est quelque chose que je n'ai jamais rencontré auparavant, donc des instructions explicites seraient grandement appréciées.

Demandé el 13 de Décembre, 2012 par Enkay

Réponses

Trop de publicités?

1voto

MadHatter avatar
MadHatter Points 77602

Je ne sais pas ce que tu gardes dans /var/www mais le contenu de mes serveurs ne peut absolument pas être qualifié d'"éphémère", ce qui signifie, selon moi, qu'il peut disparaître à tout moment, sans que cela ne me dérange outre mesure. Si ce n'est pas ce qu'amazon entend par "éphémère", je m'en excuse.

Quant à /var/log Si vous ne tenez pas du tout à ces données, ne les collectez pas.

Si vous y tenez, mais que vous ne pouvez pas vous permettre de les conserver très longtemps dans un stockage primaire, il ne s'agit pas tant d'un problème de montage que de gestion des journaux. Je serais enclin à utiliser logrotate si vous en disposez, et configurez-le pour qu'il déplace les anciens journaux vers /mnt chaque semaine ou presque. De cette façon, les anciens journaux sont là (jusqu'à ce que le stockage éphémère disparaisse), mais le journal actuel est en sécurité sur le stockage primaire.

Une recette de logrotate comme

/var/log/foo {
    olddir /mnt
    compress
    weekly
    rotate 1000
    postrotate
    /etc/rc.d/init.d/fooservice restart
    endscript
}

pourrait être utile, au moins comme modèle.

Répondu el 13 de Décembre, 2012 par MadHatter (77602 Points )

0voto

daemonofchaos avatar
daemonofchaos Points 1181

Ce que vous prévoyez est similaire à ce que je fais pour toutes mes instances, mais j'inclus également /var/lib/mysql et la plupart des répertoires /etc/{apache2,mysql,php}. Je fais cela pour ne jamais perdre mes configurations lorsqu'une instance se termine pour une raison quelconque.

  1. C'est une excellente idée dans la mesure où vous ne perdrez jamais vos données. Comme je l'ai mentionné, si l'instance tombe en panne, vous conserverez ces informations et devrez simplement les monter sur une nouvelle instance.

  2. Le plus simple est de déplacer ces répertoires vers le volume EBS, puis de créer des liens symboliques vers ces répertoires à leur emplacement d'origine.

Répondu el 13 de Décembre, 2012 par daemonofchaos (1181 Points )

0voto

Michael avatar
Michael Points 236

Si les données (sur le système de fichiers) que l'application accumule sont précieuses, ignorez le stockage complémentaire de 400 Go et montez un volume EBS. Sinon...

Les réponses dépendent (a) de votre application, et (b) de l'instance "spot" ou "réservée", mais

1) Oui, c'est une bonne idée car, évidemment, vous risquez moins de manquer d'espace disque. Cela dépend de ce que fait votre application Rails, mais juste pour la séparation et la définition claire de ce qui est "à vous" et "à moi", j'ai tendance à mettre tous les éléments "à moi" sur /mnt . Il n'est pas nécessaire de le monter manuellement. Cela se fait juste cd mnt et c'est parti. Il y a un peu de manipulation avec les autorisations, mais vous n'aurez aucun problème à les surmonter.

Mais bien sûr, cet espace est "éphémère", donc il meurt en même temps que le serveur, ce qui nous amène à ma deuxième qualification...

2) instance "spot" ou "réservée" ?

Si vous disposez d'une instance ponctuelle, vous devez accepter qu'il y a une chance, aussi minime soit-elle, que votre prix maximum soit surenchéri et que le serveur soit arrêté de manière inattendue. Cela posera un problème si les données sur le serveur ont de la valeur.

Mais ! si vous payez le prix fort pour une instance "réservée", ce qui (je n'ai pas lu toutes les clauses de non-responsabilité en petits caractères ;-/) signifie que le risque que votre serveur soit interrompu de manière inattendue, et que l'accumulation de données de l'application, est très sensiblement réduit. Vous pourriez être en mesure de programmer une sauvegarde périodique (vers S3 ?) et de dormir sur vos deux oreilles sans les frais supplémentaires d'un EBS.

À long terme, comme indiqué, l'objectif est de réduire au minimum les temps d'arrêt (et les risques). Si vous préférez payer un peu plus que de faire des économies de bouts de chandelle, alors ignorez /mnt et de se familiariser avec la création et le montage d'une EBS volume. Mettez all vos affaires là. De cette façon, vous pouvez redémarrer le serveur sans perdre le sommeil. Ces données ne disparaîtront pas et il ne faudra pas "un certain temps" pour que les choses reviennent à leur état d'avant le désastre qui a nécessité le redémarrage des instances du serveur.

Répondu el 14 de Décembre, 2012 par Michael (236 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X