Archives de catégorie : Hosting

Indisponibilité majeure…

Vous avez pu vous en rendre compte, nous avons eu deux longues soirées d’indisponibilité sur la plateforme (dimanche 6 et lundi 7 décembre).

Avant les explications sur ce qui c’est passé, un petit rappel concernant la plateforme.

En dehors des serveurs de backup (hébergés à Montpellier), toute la plateforme est hébergée dans un rack unique (donc dans une salle unique dans un datacentre unique), dans le centre de Paris (derrière le Grand Rex).

Cette plateforme c’est un châssis (Dell M1000E) avec des lames (Dell M610) et des systèmes de stockage (Equallogic PS6100E et PS6100XS) avec le réseau pour que tout ça communique.

Le châssis intègre sa propre redondance physique : seize emplacements pour des lames, deux cartes de gestion, deux systèmes de réseau (chaque lame ayant six cartes réseaux), neuf ventilateurs et six alimentations.
Il peut fonctionner avec seulement trois alimentations, une seule carte de gestion et six ventilateurs (tout ça étant bien sûr « hot plug »).

Le système de stockage, c’est la même chose : chaque baie de stockage a une double alimentation et un double contrôleur et peut fonctionner avec seulement une alimentation et/ou un seul contrôleur. Chaque baie est configurée en RAID6, avec deux disques de spare.

C’est la même chose pour le réseau. Le réseau de gestion est double (deux switches gigabits intégrés au châssis) double connecté entre eux et à deux cartes réseaux sur chaque lame, le réseau de stockage utilise deux switches gigabit externes (eux aussi double connectés entre eux et à deux cartes par lames) et, bien entendu, c’est la même chose pour le réseau « logique » (deux switches 10 Gbps dans le châssis et deux cartes 10 Gbps dans chaque lame), le tout doublement connecté.

Sur le plan applicatif, la redondance est gérée grâce aux lames en surnombre (l’ensemble des VM hébergées pourrait tourner sur seulement trois lames), avec bascule automatique en cas de soucis sur une lame.

Bref, tout est prévu. En théorie.

Parce que, pour la pratique, on s’appuie sur l’extérieur, en l’occurrence le datacentre. Datacentre qui est en théorie entièrement redondé lui aussi : double alimentation électrique, double système d’onduleurs, double climatisation et le tout séparé pour chaque salle.

Mais il y a les maintenances. Obligatoires. Qui obligent à stopper, dans le cas qui nous intéresse, une des armoires de climatisation de la salle qui perd donc la redondance « froid ».

Et ce qui avait peu de chance d’arriver est néanmoins arrivé : dimanche l’armoire de climatisation qui fonctionnait (la seule) s’est arrêtée, de 16h20 à 17h30 environ (ré-enclenchement manuel par l’équipe d’astreinte).

La température est bien entendu montée très vite et très haut : mesurée au niveau de cartes mères, on passe de 45 à 90° en une trentaine de minutes. Résultat, une des baies de stockage et le châssis se sont mis en sécurité (température trop haute) et se sont éteints. Tout simplement.

Une fois la climatisation ré-enclenchée, la température redescend (moins vite qu’elle ne monte), le châssis a redémarré seul mais pas la baie de stockage.

Il a donc fallu une intervention « Remote Hands » pour la démarrer et commencer à relancer les machines virtuelles. Et se rendre compte que certaines étaient, même démarrées, inaccessibles.

Un des switches 10 Gbps du châssis apparaissait « en alerte », tout comme deux des alimentations du châssis.

Après une nouvelle intervention « Remote Hands » qui a confirmé que le switch semblait HS, y compris après un reseat, nous avons modifié la topologie réseau et la configuration globale du châssis pour forcer l’utilisation du second switch.

Les services ont donc été rétablis aux alentours de minuit (certaines VM ont nécessité des fsck, d’autres ont du être redémarrées et certains services spécifiques également). Quelques services n’ont été accessibles que lundi matin.

Lundi vers 18h nous sommes intervenu physiquement sur la plateforme afin de vérifier le switch qui semblait HS et effectuer un re-seat des alimentations elles-même en « warning ».

Là encore, il s’est passé ce qui ne devrait pas se passer : alors que le châssis est capable de fonctionner avec seulement trois alimentations, en débranchant un des alimentations en « warning » et en la rebranchant, il s’est éteint.

Il a donc fallu tout redémarrer une fois de plus…

Les VM ont bien redémarré mais certaines fonctionnaient très mal (ça ramait, beaucoup) alors que d’autres fonctionnaient normalement.
Après investigation, il est apparu que deux lames fonctionnaient normalement alors que les quatre autres « ramaient ».

Une des lames a été libérée de ses VM et rebootée, même chose (un reboot de lame, c’est 20 minutes environ).

Nous avons alors tenté le re-seat (physique) de lame et après son boot (encore 20 minutes), les VM déplacées sur cette lame fonctionnaient correctement.

Le re-seat des trois lames restantes a ensuite été effectué (une par une pour éviter un nouveau soucis), les VM vérifiées et les services étaient de retour à 23h.

Là encore quelques services ont nécessité une nouvelle intervention mardi matin.
La topologie réseau a été corrigée et des switches « spare » ont été commandés.

Et normalement, tout devrait fonctionner sans soucis pendant quelques années.
Jusqu’à la prochaine coupure électrique (vécu à Redbus Interhouse et Overlap) ou de climatisation, que vous pourrez suivre en live via notre compte Twitter : https://twitter.com/NetworkStudioFR.

Pour la petite histoire, la maintenance de climatisation devait être terminée vendredi dernier…
Elle a finalement été terminée mardi.

La mise en place d’une plateforme mirrorée (avec un autre datacentre) est tout à fait envisageable mais pose clairement un problème de coût (nous n’avons pas la masse critique pour que cela se fasse sans une augmentation importante des tarifs).

Commentaires fermés sur Indisponibilité majeure…

Un spammeur sur un mutualisé ?

Sur un mutualisé de base (sans suphp), comment faire pour trouver le vHost sur lequel il y a le script pourri qui envoie tous les mails ?

Parce que oui, quand on regarde dans les logs du MTA, c’est « apache@serveur » (ou « www-data@serveur ») qui les envoie : aucune trace du vHost (parce que pas de « Return-Path » dans le script, bien entendu).

En fait c’est simple…

Il suffit d’ajouter une ligne dans le .htaccess de chaque vHost :

php_value mail.force_extra_parameters -fnomduvhost@serveur

Et encore mieux, si on tourne sous php 5.3.x on a un paramètre au niveau du php.ini :

; Add X-PHP-Originating-Script: that will include uid of the script followed by the filename
mail.add_x_header = On

Laisser un commentaire

Too many connections, slow down.

Orange a décidé qu’il faut parler lentement à ses MX (ça date un peu maintenant)…

Sinon les mails sont « bloqués » (le relai est bloqué en fait) avec une erreur :

status=deferred (delivery temporarily suspended: host smtp-in.orange.fr[80.12.242.148] refused to talk to me: 421 mwinf5c29 ME Trop de connexions, veuillez verifier votre configuration. Too many connections, slow down. OFR004_104 [104]

Voilà les éléments qui permettent d’adapter son postfix à Orange (compilation d’éléments trouvés sur le net et qui semblent fonctionner pour nous)…

Dans /etc/postfix/transport, on ajoute des transport spécifiques pour Orange/Wanadoo mais également pour les autres qui « filtrent » de la même manière.

wanadoo.com slow:
wanadoo.fr slow:
orange.com slow:
orange.fr slow:
nordnet.fr slow:
yopmail.com slow:
laposte.net slow:
free.fr slow:
alice.fr slow:
ymail.com yahoo:
rocketmail.com yahoo:

Dans /etc/postfix/master.cf, on crée les règles correspondantes.

#
# Slow
#
slow    unix    -       -       n       -       5       smtp
   -o syslog_name=postfix-slow
   -o smtp_destination_concurrency_limit=3
   -o slow_destination_rate_delay=1
yahoo    unix    -       -       n       -       5       smtp
   -o syslog_name=postfix-slow
   -o smtp_destination_concurrency_limit=3
   -o slow_destination_rate_delay=1

Dans /etc/postfix/main.cf, on ajoute les variables (la première ligne est peut-être déjà déclarée dans votre main.cf).

transport_maps = hash:/etc/postfix/transport, regexp:/etc/postfix/transport.regexp

slow_destination_recipient_limit = 20
slow_destination_concurrency_limit = 2
slow_destination_rate_delay = 2s
default_destination_concurrency_limit = 10

yahoo_initial_destination_concurrency = 1
yahoo_destination_concurrency_limit = 4
yahoo_destination_recipient_limit = 2
yahoo_destination_rate_delay = 1s

On définit les expressions régulières pour Yahoo, dans /etc/postfix/transport.regexp

/yahoo(\.[a-z]{2,3}){1,2}$/  yahoo:

Puis on redémarre la chose.

postmap /etc/postfix/transport
/etc/init.d/postfix restart
Laisser un commentaire

The specified virtual disk needs repair

Le besoin est simple : migrer quelques VM qui restent sur un vieux VMware Server 2.0.x vers des ESX., avec le passage d’un stockage local à un stockage partagé (une baie EQL).

La manip’ est rodée : on accède au volume local (du vieux VMware Server) via un montage NFS depuis un des ESX, puis on utilise une commande CLI (depuis la vMA) pour déplacer le vmdk de la VM tout en changeant son format…

Et là ce soir, un magnifique « Unable to clone virtual disk : A general system error occurred: The specified virtual disk needs repair ». Sur deux VM…

Google n’aide pas trop sur le coup : plein de threads avec la même erreur, grosso modo dans le même genre de situation mais pas de vraie solution. Un coup de « -a lsilogic » avec les vieux ESX, l’utilisation du store browser pour faire la copie (marche pas dans le cas de la migration depuis un VMware Server), etc. Mais rien pour résoudre mon soucis.

Donc on a ressorti les fondamentaux : le defrag !

Sur le VMware Server :

vmware-vdiskmanager -d mon_fichier.vmdk

Puis, depuis la vMA :

vmkfstools –server IP_de_mon_ESX -i « /vmfs/volumes/vmware-server/ma_VM/mon_fichier.vmdk » « /vmfs/volumes/nouveau_volume/mv_VM/mon_fichier.vmdk » -d thin

Et là, joie et bonheur, cela fonctionne !

Laisser un commentaire

Pneumatique ou électrique ?

Tout le monde se souvient de la video Shouting in datacentre.

Des études sérieuses ont été menées sur l’impact des alarmes incendies (on parle des sirènes, pas du gaz) sur la vie des disques en datacentre…

Ca fait encore un truc de plus à vérifier lors des visites.

Laisser un commentaire

Ca cause de (gros) datacentres

Ca ne s’adresse pas vraiment à nous mais ça permet d’apprendre plein de choses…
James Hamilton’s blog

Ces gros opérateurs de clouds sont définitivement les premiers à utiliser du « commodity hardware ».

Laisser un commentaire

Storage is cheap

A partir du moment où on choisit sa solution de stockage en fonction de ses besoins, storage is cheap.
Le SAN/NAS hardware n’est pas la solution ultime qui répond à toutes les problématiques, des alternatives sont possibles…

Quelques liens, en vrac, sur le sujet :
http://www.techrepublic.com/blog/datacenter/calculate-iops-in-a-storage-array/2182
http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance
http://blog.laspina.ca/ubiquitous/running-zfs-over-iscsi-as-a-vmware-vmfs-store (merci Tof)
http://www.seanodes.com/ (que nous distribuons)
http://www.nexentastor.org/
http://www.open-e.com/ (que nous distribuons aussi)
http://www.nimblestorage.com/
http://www.openfiler.com/
http://www.freenas.org/ (avec une version 8 qui support le ZFS et qui fonctionne TRES bien)

Dernière modification le 01/07/2011

Laisser un commentaire

Changement de DNS

Je passerai sur le « chez nous, on sait faire »… Un peu trop facile.

Pierre a fait un bon article, donc je lie simplement : Pourquoi « Le Monde » a-t-il brutalement disparu d’Internet vendredi matin ?

Laisser un commentaire