Comment héberger un seul site web sur plusieurs serveurs géographiquement dispersés ?

Le premier, simple, direct, et surtout, robuste La solution la plus simple est d'abandonner votre projet d'avoir deux serveurs, et de faire tourner une seule machine à partir d'un emplacement central approprié. Bien que je comprenne la raison de ne pas héberger quoi que ce soit hors de votre serveur local, en raison de la bande passante internationale limitée, je ne vois rien dans votre question qui nécessite une présence sur un serveur local.

Si vous souhaitez disposer d'un serveur local pour des raisons de performances, je vous recommande vivement d'opter pour un serveur local de ressources statiques et de transférer toutes les ressources dynamiques à Londres. Bien que geoDNS ne soit pas trivial, c'est beaucoup plus facile que la synchronisation robuste en temps réel de vos actifs dynamiques et de votre base de données. Ce mécanisme est utilisé par de nombreux sites (dont celui-ci) pour améliorer la vitesse globale perçue des pages, et il fonctionne plutôt bien.

En supposant que ce n'est pas le cas ici, et que vous avez vraiment faire Si vous avez besoin de deux serveurs, je vois une faille importante dans votre plan : la bande passante internationale de 1Mbps va être assez saturée par votre trafic de synchronisation. Il faut espérer que votre site ne devienne pas trop populaire, sinon vous serez dans un monde de douleur.

Vous êtes dans une position assez favorable vis-à-vis du DNS, car vous disposez d'un sous-ensemble clairement défini d'adresses auxquelles vous souhaitez envoyer des enregistrements particuliers. Vous pouvez probablement obtenir de votre fournisseur une liste de blocages de réseau qui délimite ce qui compte comme trafic "local, bande passante illimitée" et ce qui compte comme trafic "international, 1Mbps plafonné". Si votre fournisseur no puede Je leur demanderais comment ils font pour limiter les tarifs, car il doit y avoir une liste quelque part. Dans le pire des cas, s'ils le font simplement en se basant sur "tout ce qui est annoncé sur ce lien BGP est local", vous devriez quand même pouvoir obtenir une liste des préfixes sur ce lien.

Donc, le truc du DNS se résume à "pour A demandes d'enregistrement à www.example.com , servir localip si l'adresse source est dans la liste des préfixes locaux, et internationalip autrement". La façon dont vous script cela pour vos serveurs DNS donnés dépend de vous ; j'irais avec tinydns parce que je l'utilise pour tout ce que je peux et il est assez génial pour cette tâche particulière.

Mais c'est environ 1% du problème total. Il y a un problème beaucoup, beaucoup plus important du côté des actifs dynamiques de la ville.

La base de données est en fait la partie (relativement) facile. MySQL et PostgreSQL supportent tous deux la réplication multi-maître, grâce à laquelle les écritures dans une base de données sont répliquées dans l'autre (plus ou moins) automatiquement. Ce n'est pas exactement trivial à mettre en place, et vous devez le surveiller de près pour détecter les pannes et les réparer, mais c'est est possible d'une manière assez standardisée.

Vos fichiers, en revanche, nécessitent beaucoup plus d'intelligence locale. Pour que cela fonctionne, vous devrez concevoir votre stockage de fichiers correctement pour que la réplication puisse fonctionner. C'est encore plus amusant parce que vous dites que vous devez supporter la suppression.

Vraiment, rsync périodique est votre meilleur ami pour cela. En ignorant les aspects de modification et de suppression des choses pendant une seconde, si vous vous assurez que vos noms de fichiers ne peuvent pas entrer en collision des deux côtés (l'utilisation d'UUID ou de PK de base de données comme base pour tous vos noms de fichiers fonctionnera bien), vous devriez pouvoir faire des rsync périodiques de chaque côté vers l'autre, et tous les nouveaux fichiers créés de chaque côté apparaîtront comme par magie sur l'autre côté. La fréquence des rsync dépend du temps que vous pouvez supporter avant que tout soit synchronisé - c'est à vous de décider. Votre application doit également gérer intelligemment les cas où (par exemple) les enregistrements de la base de données sont synchronisés mais pas les fichiers.

La suppression rend les choses beaucoup plus difficiles, parce que vous ne pouvez pas simplement lancer un aveugle rsync -a --delete car tout ce que l'expéditeur n'a pas sera supprimé du récepteur - un excellent moyen de perdre beaucoup de données. Je préférerais avoir un journal des suppressions, et le parcourir de temps en temps pour supprimer des choses de l'autre côté. Si cela n'est pas intéressant, vous pouvez aller plus loin avec deux systèmes de fichiers séparés à chaque extrémité (un pour les "données locales", et l'autre pour la "réplique de l'autre extrémité"), et soit accéder aux deux depuis votre application, soit utiliser une couche de système de fichiers d'union pour les faire ressembler à un seul système de fichiers pour le serveur web.

La modification est tout simplement un cauchemar complet - votre risque est d'avoir des modifications simultanées sur les deux serveurs, et à ce moment-là vous êtes tout simplement foutu. Dans le type de modèle de "consistance éventuelle" avec lequel vous travaillez ici (qui, pour le système de réplication à haute latence géographiquement distribué avec lequel vous êtes obligé de travailler, est la seule option), vous ne pouvez tout simplement pas gérer cela au niveau de l'infrastructure -- vous devez faire une sorte de compromis au niveau de votre application pour décider comment gérer ce genre de problèmes. Vous pouvez améliorer la situation en traitant votre système de fichiers comme un magasin d'annexes seulement (si vous voulez modifier un fichier, vous écrivez une nouvelle version et mettez à jour votre base de données pour qu'elle pointe vers le nouvel enregistrement), mais comme votre base de données, elle aussi, n'est cohérente qu'à terme, vous ne pouvez pas résoudre le problème complètement. Au moins, si votre base de données est le seul point de vérité, vous aurez une cohérence garantie, sinon une exactitude garantie, ce qui est la moitié de la bataille.

Et je pense que ça couvre à peu près tout. Pour réitérer, cependant, la vie est beaucoup plus simple si vous まさか doivent opter pour des serveurs géographiquement distribués. Si vous mettez en œuvre ce projet parce qu'il "semble cool", éloignez-vous du clavier. Si vous voulez faire des choses cool, faites-le sur votre temps libre, ou comme une expérience scientifique. Vous êtes payé pour faire ce qui est le plus efficace pour votre employeur, pas ce qui vous donne un priapisme de geek.