Comme vous le savez peut-être, nous avons décidé dès le lancement d’alwaysdata de redonder nos serveurs principaux dans un second datacenter, en temps réel (via DRBD). Le but était de pouvoir rapidement pallier les pannes graves si besoin, en basculant le cas échéant l’activité sur le second serveur.

Nous allons prochainement¹ rénover la liste des bibliothèques (Python, Ruby, PHP, Perl) préinstallées chez alwaysdata. L’ensemble des bibliothèques actuellement installées sera au passage mis à jour.

C’est le moment de nous dire quelles bibliothèques vous aimeriez voir installées (via les commentaires de ce billet). Nous ne promettons pas qu’elles le seront, mais cela nous donnera une idée des plus populaires. Sachez toutefois que plus une bibliothèque est connue, maintenue et stable, plus elle a des chances d’être sélectionnée.

Nous garderons parallèlement l’ensemble des bibliothèques déjà installées avec leurs versions actuelles, pour éviter de casser les applications existantes. Le principe sera le même que pour Django ou Ruby on Rails : une sélection des versions dans l’administration alwaysdata.

C’est à vous.

¹ dans une semaine ou dans 3 mois, on ne sait pas encore. Ne nous harcelez pas

Vous nous soumettez fréquemment vos remarques et suggestions pour améliorer alwaysdata. Aujourd’hui, nous ouvrons pour la première fois un appel public à débattre sur une proposition de remaniement d’une partie cruciale de l’administration alwaysdata : la gestion des domaines et sous-domaines.

Cette proposition est détaillée dans un fil de discussion de notre forum. Nous vous invitons tous à participer et à donner vos avis. Nous n’hésiterons pas à corriger notre proposition si de bonnes idées ou remarques émergent. Merci !

Après plusieurs mois de développement et un retard à l’allumage, la nouvelle architecture est désormais en production sur tous les comptes depuis quelques jours

Ce billet ne rentrera pas dans les détails techniques de cette nouvelle architecture, pour la simple et bonne raison que j’ai donné une conférence abordant largement le sujet aux DjangoCong. Cette dernière sera disponible sous peu en vidéo – nous l’annoncerons sur le blog – et permettra alors aux curieux d’en savoir plus sur l’envers du décor.

Concrètement, cette architecture ajoute une souplesse qui va nous permettre, au fil des semaines et des mois prochains, de considérablement étoffer les fonctionnalités que nous proposons. Dans un premier temps, vous bénéficiez déjà d’un ajout important : vous avez désormais accès aux logs d’erreur et d’accès en temps réel. Deux fichiers, error.log et access.log, sont accessibles dans ~/admin/log/.

Si les logs d’accès sont un petit bonus, les logs d’erreur sont en revanche une avancée considérable : vous pourrez désormais savoir plus précisément pourquoi votre application ne démarre pas, sans avoir à nous solliciter (mais nous restons bien entendu à votre disposition, cela ne change évidemment pas).

Mais le meilleur reste à venir, et les vraies nouveautés arriveront progressivement. Le support du SSL, par exemple, qui est déjà disponible en beta (ceux qui en ont un besoin urgent peuvent nous contacter). Le support de nouvelles technologies, également (WSGI, Passenger, langages exotiques comme Erlang ou OCaml, etc.).

Nous avons profité du passage à cette nouvelle architecture pour mettre à jour le serveur HTTP principal. Cela signifie de meilleures performances, mais aussi la suppression du redémarrage régulier de vos applications, ce qui entrainait un temps de latence désagréable au premier accès.

Dernière évolution récente, sans rapport avec la nouvelle architecture HTTP : les mails sont désormais stockés sur un serveur à part, autonome. Cela veut dire qu’il y a une totale étanchéité entre nos services HTTP et mail : si un serveur HTTP devait avoir un souci, cela n’impacterait plus les mails comme c’était le cas jusqu’à présent. Par ailleurs, les lenteurs qui pouvaient être visibles en IMAP devraient être éliminées.

Ces évolutions sont un véritable tournant dans l’histoire (technique) d’alwaysdata. Nous avons commencé à y réfléchir dès 2008, et le développement a mobilisé toutes nos ressources au cours des derniers mois. Maintenant que cela est derrière nous, nous allons vraiment pouvoir vous (et nous) régaler avec des fonctionnalités concrètes.

Un grand merci, enfin, à tous ceux qui nous ont aidés : en participant au beta-test, en remontant des bugs parfois obscurs, ou tout simplement en se montant patients et confiants. Champagne¹ !

¹ avec modération.

alwaysdata sera présent aux rencontres Django à Marseille les 24 et 25 avril 2010. Nicolas et moi-même vous présenterons deux conférences :

• les dessous d’alwaysdata, qui abordera certains détails internes de notre architecture ;
• les nouveautés de Django 1.2, prévu pour le mois d’avril.

De nombreuses conférences sur Django – et en français – sont prévues pendant ce week-end. Venez nombreux pour ce premier évènement dédié au fameux framework Python en France, c’est gratuit

WebDAV fait partie des protocoles d’accès distant – avec FTP et SSH/SFTP/SCP – que nous proposons depuis le lancement d’alwaysdata. Moins connu et utilisé que ses camarades, cela pourrait bien changer avec la nouvelle implémentation que nous vous proposons depuis d’aujourd’hui.

L’implémentation originelle souffrait d’un certain nombre de défauts : incompatible avec certains clients, boguée (vitesse d’upload très faible), accessible à une adresse un peu bizarre (http://votre_compte.alwaysdata.net/webdav), etc. Nous avons donc fini par développer notre propre serveur WebDAV, aucun de ceux existants ne répondant à notre cahier des charges.

WebDAV devient désormais une excellente alternative à FTP ou SFTP en proposant de nombreux points forts :

• tous les systèmes d’exploitation modernes (Windows XP et supérieur, Mac OS X, Linux, etc.) supportent nativement WebDAV. Cela veut dire que vos fichiers distants sont intégrés à votre système de fichiers et peuvent donc être manipulés par n’importe quelle application ;
• WebDAV étant une extension à HTTP, il pose rarement problème avec les pare-feux. On oublie donc les soucis liés au mode actif/passif du FTP ;
• WebDAV permet, comme en FTP, de cloisonner (chroot) ses utilisateurs. C’est un avantage décisif par rapport à SFTP ;
• Comme le FTPS et le SFTP, WebDAV a un accès sécurisé via SSL.

Pour vous connecter à la nouvelle implémentation, suivez les indications de notre wiki. L’ancienne implémentation reste active pour quelques jours encore – les rares à l’utiliser seront contactés par email pour les alerter de la migration.

Attention : avant de vous connecter à la nouvelle implémentation, vous devez impérativement changer le mot de passe de votre utilisateur WebDAV dans l’administration alwaysdata. Vous pouvez remettre le même qu’avant : le but est simplement de générer un nouveau hash dans notre base de données (les deux implémentations utilisent un format différent).

N’hésitez pas à nous faire part de vos remarques, suggestions ou bugs. À tous ceux qui attendent le SSL sur leurs sous-domaines : ça vient, on est toujours dessus. La nouvelle implémentation WebDAV était un prérequis au déploiement de la nouvelle architecture, laquelle est elle-même nécessaire au SSL.

Elles sont en ligne ! N’hésitez pas à les lire, nous avons éliminé au maximum le blabla juridique pour ne garder que ce qui est vraiment intéressant. Et il y a de vraies nouveautés.

Nous inaugurons la garantie de service contractuelle, comme promis. 99,8 % de disponibilité par mois – soit moins de 1h30 d’indisponibilité – ou nous vous remboursons 20 % du prix mensuel par heure supplémentaire d’indisponibilité. Est exclu de ce calcul d’indisponibilité jusqu’à 2h d’opérations de maintenance qui devront être annoncées au moins une semaine en avance, et se font généralement en pleine nuit.

Ça peut sembler anecdotique, mais c’est une réelle contrainte. Ce genre de garantie est très rarement disponible chez les hébergeurs mutualisés, ou alors à des taux tellement faibles qu’ils en sont ridicules. 1h30 de panne, quand vous avez du matériel qui lâche, ça va très vite, d’où la frilosité des hébergeurs à proposer ce type de contrat.

Parmi les nouvelles un peu moins bonnes :

• nous limitons désormais à un seul compte gratuit par client, ça faisait un moment qu’on l’avait plus ou moins suggéré, sur le forum notamment
• les comptes gratuits et ceux bénéficiant de réductions (étudiant, sans emploi) ne devront pas être utilisés à des fins lucratives. Si vous voulez gagner de l’argent avec votre site, pas de problème, mais il nous semble alors légitime de payer « normalement » votre hébergeur (qui pourra continuer à offrir des réductions à ceux qui en ont vraiment besoin).

Sinon, la migration du serveur SQL a été un franc succès avec 0 problème remonté et un bon coup de fouet donné aux performances de tous vos sites – tout va maintenant très vite.  Et la nouvelle architecture – qui permettra notamment le SSL et les logs en temps réel – est entrée en beta…

Après la migration HTTP, c’est au tour de la (très attendue) migration du serveur SQL. Depuis le mois de juin dernier, une forte croissance des requêtes SQL a rendu notre serveur actuel moins véloce, ce qui a un effet immédiat sur la performance de vos sites.

Le nouveau serveur SQL a :

• 12 fois plus de RAM ;
• 4 fois plus de CPUs (chacun étant aussi plus rapide) ;
• des disques SSD.

Autrement dit, ça devrait aller vite, très vite.

Le changement de serveur est également l’occasion de mettre à jour :

• MySQL en version 5.1.39 (depuis la 5.0.32) ;
• PostgreSQL en version 8.4.1 (depuis la 8.3.5) ;
• PostGIS en version 1.3.6 (depuis la 1.3.3).

Ces mises à jour introduisent nécessairement de nombreuses petites incompatibilités mineures. Nous n’avons repéré aucune incompatibilité notable (comme celle de la version 8.3 de PostgreSQL). Dans l’immense majorité des cas, vos applications continueront à fonctionner tout à fait normalement.

Néanmoins, comme à notre habitude, nous vous laisserons la possibilité de tester vos applications avec le nouveau serveur avant de le mettre en production. C’est une simple mesure de précaution, sûrement pas une obligation. Autrement dit, si vos applications ne peuvent pas se permettre d’être hors service, vous devriez tester. Si vous utilisez PostGIS, vous devriez également tester. Sinon, ce n’est probablement pas nécessaire.

Attention, avant de tester, lisez bien tout ce qui suit :

• le nouveau serveur SQL est accessible via mysql2.alwaysdata.com et postgresql2.alwaysdata.com ;
• les données ont été importées depuis le serveur de production ce lundi 12 octobre. Le nouveau serveur contient donc des données périmées qui ne seront pas remises à jour. Le but est simplement de vous permettre d’avoir une base réelle sur laquelle tester vos applications ;
• il n’y a aucun mécanisme de synchronisation ni dans un sens (ancien -> nouveau) ni dans l’autre (nouveau -> ancien). Cela veut dire que vous ne devez pas utiliser le nouveau serveur en production, et encore moins basculer immédiatement en mettant le nouveau serveur dans vos fichiers de configuration. Toute insertion ou modification de vos données serait irrémédiablement perdue.

Typiquement, donc, vous lancerez une version de développement de votre application en remplaçant le nom d’hôte du serveur SQL par mysql2 ou postgresql2. Si vous avez une batterie de tests, lancez-la et vérifiez que tout fonctionne bien. Sinon, testez manuellement votre application pour vous assurer qu’elle fonctionne normalement.

La mise en production définitive du serveur se fera le lundi 19 octobre à partir de 2h (heure de Paris). L’opération totale devrait prendre environ 2h, mais nous essayerons de maintenir le serveur SQL en lecture seule durant le temps de la migration, pour limiter l’indisponibilité (un site en lecture seule étant souvent mieux qu’une page d’erreur).

Les serveurs principaux de notre architecture sont en train d’être remplacés. Cela nous permettra notamment de mettre fin à la période tumultueuse de ces dernières semaines, ternie par des pannes fréquentes et des performances réduites.

Serveur HTTP

Nous avons tout mis en oeuvre pour que cette migration soit la plus transparente possible pour nos utilisateurs. Pour 99,9 % d’entre vous, tout fonctionnera à l’identique sur le nouveau serveur. Mais pour éviter au 0,1 % restant de découvrir subitement que leur site ne fonctionne plus, nous allons vous permettre d’anticiper.

Pour tester votre site sur le nouveau serveur, il vous suffit d’aller sur :
http://<URL de votre site>.staging.alwaysdata.com:81

Par exemple, si l’URL de votre site est : www.excellency.fr, allez sur http://www.excellency.fr.staging.alwaysdata.com:81

Assurez-vous que votre site fonctionne normalement. Si ce n’est pas le cas, contactez-nous : nous nous engageons à vous aider à résoudre le problème, quel qu’il soit.

La migration définitive de tous les comptes vers le nouveau serveur aura lieu le 20 septembre 2009. Néanmoins, nous vous encourageons à nous contacter pour demander à être migrés avant cette date : cela vous permettra de bénéficier des performances du nouveau serveur au plus vite. Nous pourrons même convenir ensemble d’une plage horaire précise durant laquelle nous effectuerons votre migration.

Différences les plus importantes

(Cela ne parlera qu’aux utilisateurs les plus avertis. Dans l’immense majorité des cas, ces modifications seront de toute façon transparentes.)

• l’architecture passe de 32 bits à 64 bits. La plupart des applications 32 bits devraient continuer à fonctionner grâce à une couche de compatibilité, mais certains modules (.so de bibliothèques tierces) devront être réinstallés.
• certains chemins systèmes sont modifiés, notamment les répertoires des bibliothèques Python/Ruby/PHP/Perl qui passent sous /usr/local.
• certains binaires changent de nom. Pour PHP notamment, les binaires à utiliser sont désormais php5 pour le CLI et php-cgi5 pour le CGI.
• notre système d’environnement pour Python et Ruby fonctionne désormais en utilisant les binaires python2.x et ruby1.8.

Serveur SSH

Le nouveau serveur SSH entre en production à partir d’aujourd’hui (6 août) et remplace l’ancien. Il intègre les mêmes changements que le serveur HTTP.

L’IP change mais la clé de l’hôte reste identique. Vous ne devriez donc pas avoir le même message effrayant qu’il y a quelques semaines.

Serveur SQL

Les serveurs MySQL et PostgreSQL seront également mis à jour prochainement. Les modalités de cette migration seront explicitées à l’occasion d’un prochain billet.

Bonus

Ces nouveaux serveurs apportent également quelques bonnes surprises :

• Python 2.6, 3.1
• PHP 5.2.10, 5.3
• Ruby 1.8.7
• AjaxTerm en HTTPS

Ces nouvelles versions coexistent avec les anciennes. Il n’est pas possible de les sélectionner pour le moment dans notre interface administration tant qu’il restera des comptes sur l’ancien serveur. Mais cela devrait ravir certains d’entre vous j’en suis sûr

Offrir un hébergement mutualisé stable et performant a toujours été l’un de nos objectifs principaux. Depuis plus de 2 ans, cet objectif était rempli – notre forum est là pour en témoigner.

Depuis la fin du moins de juin, nous traversons une difficile période de transition de notre architecture. Cette transition, prévue de longue date et ayant pour but de maintenir – et même améliorer – la qualité du service que nous offrons, a pris un retard important.

Parallèlement, nous avons connu de bien trop nombreuses pannes durant tout le mois de juillet. À ce jour, ces pannes additionnées portent notre indisponibilité HTTP à 4h14, soit 99,44 % pour ce mois-ci, contre plus de 99,9 % habituellement. C’est, de très, très loin, le plus mauvais mois depuis nos 26 mois d’existence. C’est une disponibilité qui fait honte à alwaysdata, et à moi.

J’aurai l’occasion, dans un futur billet, de revenir en détails sur les raisons de ces pannes. Aujourd’hui, je veux vous dire que ce mois de juillet n’est pas représentatif de ce qu’alwaysdata est en train de devenir. Nous ne croyons pas à la fatalité de l’hébergeur dont la qualité baisse à mesure que le nombre de ses clients augmente.

Le développement de notre nouvelle architecture touche à sa fin et nous allons bientôt commencer à la migration des comptes. Notre service retrouvera alors sa stabilité habituelle. D’autres modifications techniques sont même prévues par la suite pour améliorer cette stabilité.

Mais nous allons faire plus. À partir de la rentrée prochaine, nous allons :

• vous garantir contractuellement un taux disponibilité avec pénalités financières en cas de non respect. Le taux et les pénalités sont encore à définir, mais ils seront contraignants (pour nous) : pas question de garantir un ridicule 99 %.
• mettre en place un site permettant de voir l’état de nos services – en temps réel – et l’historique de nos pannes. C’est une seconde contrainte pour nous : nos pannes resteront à jamais enregistrées et visibles par tous. Parallèlement, nous communiquerons sur un compte Twitter qui nous permettra de rester en contact même en cas de panne massive de notre infrastructure.

À tous nos clients, je veux présenter mes plus sincères excuses concernant cette situation. Je pense encore plus particulièrement à tous ceux qui doivent se justifier auprès de leurs propres utilisateurs ou clients. Je pense aussi à ceux qui se sont inscrits chez alwaysdata depuis quelques semaines et qui ont une image désastreuse de notre service.

Merci à tous, enfin, pour votre compréhension et votre patience.