2015-06-01 9 views
11

Ho letto in Akka documentation che quando si utilizza il singleton cluster si dovrebbe evitare l'utilizzo del downing automatico. Non capisco come debba essere configurato downing in quel caso. Capisco che potrei iscrivermi agli eventi di appartenenza al cluster e pianificare la mia strategia in base a quei messaggi. Tuttavia, non capisco quanto sarà praticamente diverso dal downing automatico.Come configurare downing nel cluster akka quando è presente un singleton

Quando un nodo è partizionato in qualche modo dal cluster, se viene utilizzato il downing automatico, il nodo partizionato "penserà" che l'intero cluster è scomparso e avvierà un cluster proprio (con il proprio singleton). Ma, d'altro canto, non posso mantenere i nodi irraggiungibili in uno stato non raggiungibile per sempre perché il cluster non raggiungerà la convergenza (i nuovi nodi non saranno in grado di unirsi) e se il nodo partizionato è il singleton stesso un nuovo singleton il nodo non sarà assegnato e quindi, secondo la mia comprensione, l'unica cosa che rimane da fare è rimuovere nodi irraggiungibili dopo un certo periodo di grazia che è esattamente ciò che fa il downing automatico.

Cosa mi manca qui?

+0

ho la stessa domanda, come si. sembra che non abbiamo alcun modo per impedire partizione 2 cluster di avviare un'attività in proprio cluster Singleton – mingchuno

risposta

1

controlla il codice seguente. Ho disattivato la funzione auto-down-unreachable-after come indicato dal documento. Invece, implemento una logica personalizzata che è leggermente diversa dalla norma. La chiave del codice qui sotto è se la partizione di rete si verifica, solo i nodi cluster che hanno la maggioranza proveranno UnreachableMember dopo alcuni 5 configabili. D'altro canto, la minoranza dei nodi del cluster calpesterà il proprio UnreachableMember (che è il gruppo maggioritario come unreachable e non li porterà giù per formare un'isola. L'idea del numero di maggioranza è presa in prestito da MongoDB che penso sia non è nuovo nella zona di informatica.

class ClusterListener extends Actor with ActorLogging { 

    val cluster = Cluster(context.system) 
    var unreachableMember: Set[Member] = Set() 

    // subscribe to cluster changes, re-subscribe when restart 
    override def preStart(): Unit = { 
    //#subscribe 
    cluster.subscribe(self, initialStateMode = InitialStateAsEvents, classOf[UnreachableMember], classOf[ReachableMember]) 
    //#subscribe 
    } 
    override def postStop(): Unit = cluster.unsubscribe(self) 

    def receive = { 
    case UnreachableMember(member) => 
     log.info("Member detected as unreachable: {}", member) 
     val state = cluster.state 
     if (isMajority(state.members.size, state.unreachable.size)) { 
     scheduletakeDown(member) 
     } 
    case ReachableMember(member) => 
     unreachableMember = unreachableMember - member 
    case _: MemberEvent => // ignore 
    case "die" => 
     unreachableMember.foreach { member => 
     cluster.down(member.address) 
     } 
    } 

    // find out majority number of the group 
    private def majority(n: Int): Int = (n+1)/2 + (n+1)%2 

    private def isMajority(total: Int, dead: Int): Boolean = { 
    require(total > 0) 
    require(dead >= 0) 
    (total - dead) >= majority(total) 
    } 

    private def scheduletakeDown(member: Member) = { 
    implicit val dispatcher = context.system.dispatcher 
    unreachableMember = unreachableMember + member 
    // make 5s config able!!! 
    context.system.scheduler.scheduleOnce(5 seconds, self, "die") 
    } 

} 
+0

Grazie per il tuo commento, ma non capisco qualcosa Quando i nodi partizionati (di minoranza) tornano alla maggioranza, diciamo che i problemi di rete/gc sono stati risolti, a meno che i nodi di minoranza non riavviino il loro sistema di attori (per rigenerare un nuovo token), sarebbero in grado di connettersi nuovamente alla maggioranza ? Perché per quanto ne so Se a il nodo è stato eliminato dal cluster e non può essere restituito con lo stesso token. – Mizh

+0

Ciao, so che questo è vecchio. Ma per chiunque cerchi la risposta. I nodi partizionati contrassegnati come inattivi dalla maggioranza dovrebbero essere riavviati in modo esplicito per poter accedere nuovamente al cluster. http://doc.akka.io/docs/akka/2.4.2/scala/cluster-usage.html#Joining_to_Seed_Nodes – Cal

+1

Ho provato questo su Akka 2.4.3 e ho confermato che funziona. Ho due macchine, eseguo la maggior parte dei miei nodi sulla macchina A e una minoranza sulla macchina B. Interrompo la connessione tra A e B per simulare una partizione. I nodi A della macchina Un problema di rimozione sulla minoranza (nodi della Macchina B) e i nodi di minoranza sono in grado di rendersi conto che sono in realtà la minoranza. Si noti che i nodi di minoranza non terminano se stessi e rimangono in esecuzione. È necessaria una logica aggiuntiva per chiuderli. Cerca "akka cluster split brain e riconnettiti" per maggiori informazioni. Grazie per aver condiviso @mingchuno – Cal