eu explorez Cozi de cvorum RabbitMQ pentru a îmbunătăți HA pentru unele servicii dintr-un cluster Kubernetes. Pe măsură ce citesc, acestea sunt concepute având în vedere siguranța datelor.
Însă capitolul „Gestionarea replicilor” afirmă:
Replicile unei cozi de cvorum sunt gestionate în mod explicit de către operator.
Când un nou nod este adăugat la cluster, acesta nu va găzdui nicio coadă de cvorum
replici, cu excepția cazului în care operatorul îl adaugă în mod explicit unui membru (replica)
lista unei cozi de cvorum sau un set de cozi de cvorum.
Se pare deci că, în cazul întreruperi (în special involuntar), ar putea apărea următoarea situație (pentru un cluster cu 3 noduri):
- după o întrerupere un nod ar cădea: celelalte două noduri încă compun majoritatea și vor „ține coada vie”, eventual alegând un nou lider;
- kubernetes va furniza un nou nod (pod) pentru a înlocui nodul eșuat; noul nod se va alătura automat cluster-ului RabbitMQ, dar
- cu excepţia cazului în care operatorul intervine manual, noul nod va nu contribuie la cozile de cvorum existente;
- pentru un cluster cu 3 noduri, aceasta înseamnă că nu mai există HA: dacă, cândva în viitor, unul dintre celelalte noduri eșuează, coada este efectiv pierdută;
Există vreo modalitate de a atenua acest scenariu? Este, de exemplu, posibil ca nodurile să se alăture automat toate clusterele existente de cozi de cvorum? Poate prin menținerea unei liste de „comenzi de pornire” (care rulează după pornirea RabbitMQ) la care am putea adăuga reunește comenzile?
