Synkronisere aktivitet og sikre kun en udførsel på tværs af servere

Det nemmeste er nok at bruge en database til at synkronisere web serverne.

En database som understoetter transaktioner, transaction isolation level >= repeateable read, SELECT inuse FROM synctbl og UPDATE synctbl SET inuse = TRUE.

Saa saetter du cron eller andet til at kalde PHP kode paa all noder, men kun af dem faar lov til at saette flaget og lave det som skal laves.

Det må du lige uddybe arne_v, du vil bruge transaction til at sikre, at en af noderne ikke opdaterer, imens en anden allerede er i gang med processen. Så langt så godt, men hvad mener du med resten?

Og hvordan sikrer du dig, såfremt database-serveren går ned? Ideelt set, så jeg jo helst at der ikke var nogen hoved-server, som alle var afhængige af.

Der er et flag i databasen som bruges til at laase med.

Transaktion bruges til at sikre at SELECT af flag og UPDATE af flag kan laves atomisk.

Der er vel en standby database server som tager over hvis database server gaar ned??

Hvad mente du med følgende:


Men som udgangspunkt er der ikke nogen database-server til at overtage, princippet er, at jeg I vil sætte det op på php-webhoteller på tværs af forskellige udbydere.

Går én webserver/webhost helt ned, vil jeg gerne have at de andre kan klare opgaven. Uanset hvilke(n) webserver der går ned.
Det jeg sørger er dybest set at lave min egen lille decentraliserede cloud. Jeg er dog opmærksom på, at der vil være tale om forskellige IP-adresser/domæner, som man vil skulle afprøve i tilfælde af, at en eller flere af noderne er nede.

Giver det mening?

Min egen tanke var noget i stil med, at server A skal fortælle/indhente accept fra over halvdelen af noderne, for at kan udføre opgaven. Lige så snart server A, har informeret de andre servere om dette, vil de jo så ikke udføre opgaven, og en eventuel server B vil ikke kunne få accept fra over halvdelen til også at udføre opgaven.

Denne fremgangsmåde betyder dog, at der potentielt kan gå ret lang tid førend en server har kontaktet minimum halvdelen af serverne. Så jeg tænkte, at der nok var en bedre måde. Men måske man skal ind og se på noget med én central (database-)server.

transaction isolation level >= repeateable read er noedvendigt for at metode med foerst en SELECT og saa en UPDATE virker.

Du kan godt lave en loesning med in-memory data og kun kommunikation over netvaerk. Det du har bruge for er ogsaa kendt som en DLM - distributed lock manager.

DLM er typisk noget man bruger i OS og database kode skrevet i C eller i nogen af de nyere big data thingie skrevet i Java.

Jeg kan ikke umiddelbart finde noget om en saadan i PHP.

Ud fra dit indlæg om DLM, har jeg kigget lidt nærmere på ZooKeeper. Med denne viden og dine svar, er jeg kommet frem til, at der nok skal udpeges én hovedserver. Ved fejl, må de andre servere, så sørge for automatisk at udpege en ny.

ZooKeeper fungerer ved at alle write operationer sendes til hovedserveren, som så iværksætter synkronisering med alle de andre servere. Dette princip kunne man sådan set sagtens kopiere. Og så selvfølgelig anvende transactions på hovedserveren.

Mit bud på en løsning:
Hovedserver:
Antag at vi har n=10 servere. Så snart en server (S1) ikke kan kontakte hovedserveren spørg den de andre servere, om de har forbindelse. Er der ikke forbindelse til hovedserveren udpeges S1 som ny hovedserver. Såfremt S1 ikke får nogle svar, anses den som værende afskåret. Når der igen er forbindelse til de andre, skal S1 derfor synkronisere på ny.

Synkronisering:
En klient kontakter S2 med en write-forespørgsel. S2 kontakter hovedserveren, som også gemmer en log om forespørgselen. Hovedserveren accepterer og sender en opdatering rundt til alle servere med ændringen. S2 svarer klienten.

Ved simpel read-forespørgsel til S2, svarer S2 klienten ud fra egen data. En log sendes til hovedserveren.

Planlagte opgaver m.m.
Alle serverne sørger på det planlagte tidspunkt at kontakte hovedserveren, som kun tillader første mand at udføre opgaven. Såfremt hovedserveren er utilgængelig, vælges først en ny, hvorefter opgaven udføres.

Bør man overveje deadlock problemer, såfremt S2 har fået tilladelse til at udføre en opgave, men aldrig vender tilbage, når den er løst? Nogen gode forslag hertil?

Det er vel muligt at teste paa om opgaven er fjordt faerdig eller ej.

Det er almindeligt med keep-alive messages saaledes at en node der er nede hurtigt opdages.

Husk at der altid skal vaere >50% af noderne tilstede (quorum) for at undgaa split brain problemer.

Jeg vil fraraade dig at forsoege at implementere saadan noget fra bunden af. Det er meget tricky at faa korrekt.

Og PHP's fleksible ekskverings-model goer det endnu vanskeligere.

Enten brug en database.

Eller koer noget eksternt ved siden af PHP som PHP kan kommunikere med.

Jeg synes jo fordelen ved at lave det selv, var at man undgik afhængigheden af én (database-)server. Men det kan da godt ske du har ret i, at det ikke bliver for komplekst til at man kan opnå et ordentligt resultat.

At saette 2 database servere op saa den anden tager over hvis den foerste gaar ned er helt standard.

Den ande mulighed var at koere noget andet (formentligt skrevet i Java) ved siden af Apache+PHP paa web serverene og lade PHP snakke med det via noget IPC/netvaerk kommunikation.

Jeg prøver mig frem med at lave min egen PHP-løsning, og vil så prøve at stress-teste den lidt. Så må vi se hvordan det hele performer.

Det kan meget vel være jeg ender med at bruge database-løsningen, men i første omgang, synes jeg, det kunne være interessant at lære lidt mere om DLM og de dertilhørende problemstillinger.

Læg et svar for din gode hjælp og kvalificerede råd!

svar