Kobasica od naslova, ali, treba mi pomoć oko definisanja arhitekture sistema po sledećim zahtevima:
1. Sistem se sastoji od nekoliko web aplikacija, koje su u sklopu fajlsistema i baze - dakle, fajlsistem čuva uploadovane fajlove i generisane fajlove npr. thumbnails, PDF-ove, itd., a baza čuva naravno sve ostalo. Aplikacije su PHP+MySQL combo, ima i nešto NodeJS ali je baza uvek MySQL
2. Sistem već postoji, hostuje se na jednom serveru
3. Zbog specifičnosti same industrije koja je predmet sistema, neophodno je da sistem ima visoku dostupnost. Identifikovan je faktor rizika na nivou datacentra
3.1. Inače, u prethodnih 6 meseci se u Telenorovom tj sada CETIN datacentru stalno neke havarije dešavaju čas sa mrežom čas sa strujom, tako da je dolazilo do potpune nedostupnosti servisa po dva sata u toku radnog vremena što je nedopustivo
4. Plan je, pošto već postoje uslovi za kolokaciju u još dva datacentra, od kojih je jedan izvan BG i ne ide kroz SOX, da se nekako radi replikacija baze na tri servera
5. Pretpostavimo da serveri imaju bezbedan intranet link za komunikaciju kao da su u LAN-u
6. ovde dolazim do problema - klasična MySQL replikacija ima master i slave, ali meni ne znači da mi je dostupna read-only baza na druga dva servera već u slučaju da primarni server "crkne", saobraćaj će biti preusmeren na neki drugi, koji će replikacijom u tom trenutku biti up to date sa unosima u bazi a fajlove će cron job kopirati uz hook kada se nešto upiše da se odmah triggeruje push na slave servere. E sad, dolazi do problema šta kada primarni server ponovo proradi - treba se podaci nazad sinhronizovati na njega.
7. Koristi se cloudflare i njegov load balancer servis
Meni je u planu bilo da koristim MySQL replikaciju, i da serveri rade po principu one time trigger-a, gde kada server ode offline, više se ne može koristiti za saobraćaj dok se na njega ne izvrši sinhronizacija. Tako je pokriven scenario gde server 1 crkne, pa saobraćaj ode na server 2, ako i on crkne, ode na server 3, a u svakom trenutku će serveri 2 i 3 biti identičnog state-a. Fajlsistem sinhronizacija nije problem.
Problem je samo kako odraditi da se server 2 ili 3 sinhronizuju nazad na server 1, čime bi on ponovo bio primarni.
Konkretno nije bitno koji server je primarni, bitno je samo da se zaštiti od failure moda kada je ceo datacentar offline. U slučaju problema unutar datacentra, traffic će se rutirati na neki drugi server koji će koristiti jedan od dostupnih db servera koji su replicirani u istom master-slave fazonu. Ali mi je ta inter-DC sinhronizacija problem kada se otkloni kvar, treba podatke "vratiti nazad" na primarni server.
Predlozi?
1. Sistem se sastoji od nekoliko web aplikacija, koje su u sklopu fajlsistema i baze - dakle, fajlsistem čuva uploadovane fajlove i generisane fajlove npr. thumbnails, PDF-ove, itd., a baza čuva naravno sve ostalo. Aplikacije su PHP+MySQL combo, ima i nešto NodeJS ali je baza uvek MySQL
2. Sistem već postoji, hostuje se na jednom serveru
3. Zbog specifičnosti same industrije koja je predmet sistema, neophodno je da sistem ima visoku dostupnost. Identifikovan je faktor rizika na nivou datacentra
3.1. Inače, u prethodnih 6 meseci se u Telenorovom tj sada CETIN datacentru stalno neke havarije dešavaju čas sa mrežom čas sa strujom, tako da je dolazilo do potpune nedostupnosti servisa po dva sata u toku radnog vremena što je nedopustivo
4. Plan je, pošto već postoje uslovi za kolokaciju u još dva datacentra, od kojih je jedan izvan BG i ne ide kroz SOX, da se nekako radi replikacija baze na tri servera
5. Pretpostavimo da serveri imaju bezbedan intranet link za komunikaciju kao da su u LAN-u
6. ovde dolazim do problema - klasična MySQL replikacija ima master i slave, ali meni ne znači da mi je dostupna read-only baza na druga dva servera već u slučaju da primarni server "crkne", saobraćaj će biti preusmeren na neki drugi, koji će replikacijom u tom trenutku biti up to date sa unosima u bazi a fajlove će cron job kopirati uz hook kada se nešto upiše da se odmah triggeruje push na slave servere. E sad, dolazi do problema šta kada primarni server ponovo proradi - treba se podaci nazad sinhronizovati na njega.
7. Koristi se cloudflare i njegov load balancer servis
Meni je u planu bilo da koristim MySQL replikaciju, i da serveri rade po principu one time trigger-a, gde kada server ode offline, više se ne može koristiti za saobraćaj dok se na njega ne izvrši sinhronizacija. Tako je pokriven scenario gde server 1 crkne, pa saobraćaj ode na server 2, ako i on crkne, ode na server 3, a u svakom trenutku će serveri 2 i 3 biti identičnog state-a. Fajlsistem sinhronizacija nije problem.
Problem je samo kako odraditi da se server 2 ili 3 sinhronizuju nazad na server 1, čime bi on ponovo bio primarni.
Konkretno nije bitno koji server je primarni, bitno je samo da se zaštiti od failure moda kada je ceo datacentar offline. U slučaju problema unutar datacentra, traffic će se rutirati na neki drugi server koji će koristiti jedan od dostupnih db servera koji su replicirani u istom master-slave fazonu. Ali mi je ta inter-DC sinhronizacija problem kada se otkloni kvar, treba podatke "vratiti nazad" na primarni server.
Predlozi?