Est-ce que cet équilibrage de charge / plan d'échelle horizontale est naïf?

J'offre ma solution au problème suivant et je request aux professionnels de l'administration du réseau et du server de le valider ou de poke des trous. Je suis intéressé par des vectors d'attaque évidents ou des problèmes d'évolutivité que vous pouvez constater. Merci!

Exigences:

  • Le support HTTPS, géré par chaque server d'application indépendamment
  • évolutivité horizontal presque linéaire
  • la bande passante répartie entre les servers (datatables de réponse ne returnnent pas toutes par les LB ou les proxies)
  • quelque chose comme le basculement pour les servers d'applications et les équilibreurs de charge
  • Affinité client-server
  • Linux-friendly (solution non fermée)
  • Amicalement compatible avec le bootstrap! (c.-à-d. coût initial faible)

Le schéma:

PUBLIC NETWORK +-----+------+--------+-----+-------> | | | | vvvv +---+ +---+ +--+ +--+ |LB1| |LB2| ... |S1| |S2| ... +---+ +---+ +--+ +--+ 

Les équilibreurs de charge redondants (LB *, par quelque chose comme DNS RR ou simplement par basculement): leur seul but est d'offrir aux clients l'URI à une instance de server d'applications, que le client utiliserait à perpétuité pour ses requests. La dissortingbution serait au hasard ou au rondeur, au départ.

Les instances du server d'applications (S *) gèrent indépendamment les requests directement des clients.

L'architecture sans État permet aux servers individuels de diminuer. Les clients requestnt un nouveau server des équilibreurs de charge si leur server assigné échoue.

Les nouveaux servers d'applications pourraient tourner, s'inscrire auprès des équilibreurs de charge et être affectés aux clients très rapidement. Tout S * aurait une input DNS de sous-domaine pour partager un certificate générique.

Une implantation naïve pourrait être effectuée entièrement sur un server avec une redondance nulle, et déléguer les responsabilités à développer au besoin.

Préoccupations immédiates

Le pare-feu et la protection DDoS devraient être gérés dans chaque server, au lieu de centralement comme vous l'avez avec des templates inversés d'équilibrage de charge. La gestion de la configuration centralisée est autant que je l'ai pensé.

Ce schéma ne profite pas de l'location géographique ou du time de réponse du server, comme quelque soit Anycast DNS. C'est un compromis conscient pour une plus grande probabilité d'affinité du server, et peut éventuellement être rajouté plus tard.

Sur un niveau élevé, il semble être correct mais il y a des lacunes dans le schéma.

  • Expliquez comment le client sait se replier si un server descend. (le plus gros problème je pense)
  • Expliquez comment vos équilibreurs de charge fournissent juste un URI. Ces servers sont-ils simples?
  • Comment manipuler des données détachées telles que des cookies de session qui peuvent transmettre des données implicites à un server précédent. Sinon, vous utilisez des cookies normaux?
  • Comment vous inscrire à l'équilibreur de charge?
  • Comment le stockage fonctionnerait-il dans cette design? Comment cette échelle?
  • Comment un équilibreur de charge fait-il réellement équilibrer la charge dans ce schéma? Étant donné que tout ce qu'il offre sont des renvois, il n'y a aucun moyen de savoir quand une session s'est terminée sur le côté du server.
  • Comment un équilibreur de charge sait-il si un server est en panne?