web-dev-qa-db-fra.com

equilibrage de charge gRPC

J'ai lu la page sur l'équilibrage de la charge à l'adresse suivante: https://github.com/grpc/grpc/blob/master/doc/load-balancing.md au début de, mais je ne comprends toujours pas quelle est la bonne approche pour équilibrer la charge. entre les instances GRPC dorsales. Nous déployons plusieurs instances de «microservice» de gRPC et souhaitons que nos autres clients gRPC puissent être routés entre eux. Nous les déployons sous forme de modules dans kubernetes (en fait, Google Container Engine).

Quelqu'un peut-il expliquer l'approche "recommandée" pour équilibrer la charge des demandes de clients gRPC entre les serveurs gRPC? Il semble que les clients doivent connaître les points de terminaison. N’est-il pas possible de tirer parti de LoadBalancer intégré dans Container Engine pour l’aider?

8
user3707

Je ne peux pas parler de kubernetes, mais en ce qui concerne l'équilibrage de charge de gRPC, il existe essentiellement deux approches:

  1. Pour les cas d'utilisation simples, vous pouvez activer la répétition alternée de la liste des adresses renvoyées pour un nom donné (c'est-à-dire la liste des adresses IP renvoyées pour service.foo.com). La manière de le faire dépend de la langue. Pour C++, vous utiliseriez grpc::ChannelArguments::SetLoadBalancingPolicyName avec "round_robin" comme argument (à l'avenir, il serait également possible de sélectionner via " service configuration ", mais la conception permettant d'encoder cette configuration dans les enregistrements DNS n’a pas encore été finalisée).
  2. Utilisez le protocole grpclb. Ceci convient aux déploiements plus complexes. Cette fonctionnalité nécessitait le résolveur DNS c-ares , que # 11237 introduit (ce RP est sur le point d'être fusionné). C'est la pièce qui manque pour que grpclb fonctionne en open source. En particulier:
    • Regardez ce document . Il passe en revue les modifications de configuration DNS nécessaires pour contrôler les adresses marquées en tant qu'équilibreurs. C'est actuellement une "proposition", qui devrait être promu au doc ​​prochainement. Cela peut être pris assez avec autorité, c'est ce que # 11237 est en train de mettre en œuvre pour la découverte de l'équilibreur.
    • Ecrivez un serveur gRPC standard (quelle que soit la langue) en implémentant le protocole de l'équilibreur de charge . Il s’agit du serveur à marquer dans vos enregistrements DNS en tant qu’équilibreur (comme décrit dans le document susmentionné ), avec lequel le groupe grpclb du client communiquera pour obtenir la liste des adresses d’arrière-plan (appelé listes_serveur ). C'est à vous de rendre la logique à l'intérieur de cet équilibreur aussi simple ou aussi complexe que vous le souhaitez.
    • Le client utilisera le nom DNS de balancer lors de la création d'un canal. Notez également que le nom DNS de votre équilibreur peut pointer vers plusieurs adresses. Si un ou plusieurs d’entre eux sont marqués comme équilibreurs, grpclb sera utilisé. Quel équilibreur sera choisi s'il y en a plus d'un? Le premier auquel le client se connecte.

Faites moi savoir si vous avez des questions.

8

Comme mentionné par Samarendra

Vous pouvez vérifier Envoy , construit à l'origine par Lyft.

Il offre un support de première classe pour HTTP/2 et gRPC pour les connexions entrantes et sortantes.

  • Equilibrage de charge L7 pour gRPC
  • service de découverte de grappes (ex. consul)

Nous utilisons des émotions pour nos services de gRPC à Gojek, qui nous sert bien sous une charge assez élevée. 

3
Mehak Kahlon

Pour l’équilibrage de charge entre les serveurs grpc, l’équilibrage de charge par défaut de Kubernate ne vous aidera pas car il s’agit d’un équilibreur de charge L4.

Pourquoi L7?

grpc utilise http2 où les connexions sont persistantes et les requêtes seront envoyées via la même connexion. L'équilibreur de charge L4 équilibrera la charge à l'aide de connexions TCP, mais vous avez besoin d'un équilibre de charge au niveau de la demande. Nous aurions donc besoin d'un équilibreur de charge L7. surtout quand la communication est entre les serveurs de grpc.

il existe plusieurs options, vous pouvez utiliser Linkered/Envoy pour cela, elles fonctionnent bien avec kubernates et fournissent également un bon service.

pour exposer vos services à des travaux extérieurs, vous pouvez utiliser nghttpx et nghttpx Ingress controller.

vous pouvez également utiliser l'équilibrage de la charge côté client, mais cela ne me semble pas rentable.

1
Samarendra

Vous voudrez peut-être consulter nghttpx et le contrôleur de nghttpx Ingress projects. Ces projets permettent d’équilibrer la charge de L7 pour les flux HTTP/2.

Consultez également le site https://cloud.google.com/endpoints/docs/architecture-overview pour obtenir des informations sur la gestion des points de terminaison intégrée à Google Cloud Platform.

0
MarkNS

Si dans AWS/ECS a https://aws.Amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/ fonctionnera pour contourner les connexions entre vos groupes cibles.

Vous devez faire quelque chose pour écouter le bilan de santé que NLB ne peut faire que dans HTTP1. Aussi, vous arrivez à mettre fin à votre propre SSL.

0
jdwyah