Structura Aplicatie High Availability

Salut,
As avea nevoie de o solutie de la voi ( cei care au implementat asa ceva )
Am urmatoarea structura :

  1. Server web cu web app
  2. Subdomeniu /api/ pentru API
  3. Applicatii mobile care se conecteaza pe pe /api/ cu notificari

Serverul de mai sus va avea mirror pe server2 in alta locatie/alt provider.odata la 5 minute ( Mysql master slave + rsync la 5 minute )
As dori sa imi recomandati o solutie de DNS management in cazul in care este Host failure / ISP failure in care sa pot face switch de pe server1 (main ) pe server2 pana la remedierea problemelor.

Stiu ca toata lumea recomanda cloud si solutii 2017. Doar ca am 2 probleme cu cloud-ul :

  1. Si cloud-ul cade si atunci ii single point of failure
  2. Costurile pentru “ceva custom” sunt teribile.

Multumesc

1 Like

Salutare!

Sunt in acceasi situatie :slight_smile:

Pentru DNS balancing voi folosi ceva de genul:

Spor

2 Likes

Route53 stie de health checks si failover.

Haproxy? http://www.haproxy.org

2 Likes

Round-robin pe DNS direct s-ar putea sa nu fie ce vrei exact, deoarece pare ca la tine un DC este “master”, iar celalalt “slave”. Vrei mai degraba ceva in care trimiti mereu traficul spre prima instanta, iar daca aia pica, trimiti spre a doua. Ceva gen active-passive failover. Pe cloudflare arata asa.

Adauga-ma si pe mine la toata lumea. Cloud-ul pica intr-adevar, dar (1) mult mult mai rar decat orice poti sa incropesti ca non-profesionist in domeniu si (2) pica pe bucati - adica nu pica tot AWS-ul deodata, ci doar un datacenter sau un serviciu. In toate cloud-urile ai conceptul de “availability zone”, care e o bariera pentru probleme. Daca rulezi aplicatia in 2+ az-uri ar trebui sa fi ferit de probleme in acelasi mod in care il propui tu aici cu doi provideri separati.

3 Likes

alte chestii care nu se mai fac in 2017 :slight_smile: (no-offence)

  • rsync pt static content; try DRBD + LVM pt block level sync + snapshots
  • mysql master-slave; try mariadb 10.2 cu galera, master-master si cu viteza excelenta prin wan

Cat pt DNS, daca nu vrei un serviciu extern de failover, cam singura optiune e sa faci BGP + keepalived care face nsupdate cand detecteaza fail, si bineinteles un TTL de zona de ~300 (oricum ISP ignora si fac caching agresiv)

3 Likes

Cloudflare pentru DNS + Galera Cluster/ Percona XtraDB Cluster + Amazon AWS cu containere docker pentru backend-ul php platit pe ora/serverless pe accesare + un CDN global pentru frontend + un load balancer cu round robin global in fata containerelor care ruleaza pe amazon aws on-demand (poate fi cloudlflare, dar poate AWS Elastic load balancer e mai ieftin).

Pentru mysql folosesti ZFS pentru stocare si faci snapshot-uri la intreg vm-ul in care ruleaza un server din cluster pe un server de backup. Poti face containerele sa faca ping spre serverele mysql si sa seteze in environment variables serverul care e online sau are cel mai mic load pentru php.

Eu nu prea inteleg chestia cu backup la snapshot. Pai si daca exact la snapshot prinzi fisierele deschise de serverul SQL in “invalid state”? Te trezesti ca ai salvat fisiere corupte…

Nu are treaba, https://dev.mysql.com/doc/refman/5.6/en/ha-zfs-replication.html

Pe InnoDB/XtraDB nu ar trebui sa fie probleme :slight_smile:

De ce pe InnoDB n-ar trebui sa fie probleme? Esti absolut sigur ca scrierea pe filesystem este atomică? Mie orice scriere pe HDD imi da impresia ca niciodata nu poti sa fii sigur la un moment dat pe consistenţa (imi scapă termenul în română :slight_smile:) datelor dintr-un fişier deschis.

We lock the MySQL tables and flush them thereby clearing caches and making sure the latest data is written to disk.

We take a snapshot of the file system with zfs snapshot.

We unlock the MySQL tables.

Dar citez pentru InnoDB :
InnoDB can recover data from transaction commit logs without data loss.

Deci daca ai probleme cu coruperea datelor cu InnoDB e probabil din cauza vreunui bug.

Well, parca nu sună prea bine că un backup “can be recovered” :slight_smile: Un backup e o chestie pe care trebuie sa te poţi baza că este 100% “freeze”. Mi se pare aiurea să am un set de date care ar trebui sa fie “recuperate” de un proces oarecare, după reguli numai de el ştiute.

După mine, sunt doua variante “safe”: (1) dacă vrei sa faci backup “online”, folosesti mysqldump. (2) Dacă vrei să copiezi fisirele raw ale bazei de date, opreşti serverul sql, faci snapshot, pornesti serverul sql, copiezi fisierele din snapshot, stergi snapshot-ul. In afara de asta, ţin ultimele 30 de copii ale backup-urilor zilnice, in caz ca sunt hackerit (sau datele sunt corupte intr-un fel sau altul) si vreau sa am de unde sa iau date “curate”.

1 Like

InnoDB e foarte bun la self-recoveri, iar cu IO_DIRECT + innodb_flush_log_at_trx_commit iti dau suficienta viteza de scriere pe disk incat sa dormi linistit in cele mai des intalnite cazuri de baze de date (alea cu heavy reads)

In cazuri de mission impossible, daca mai adaugam la cele de mai sus si o replicare sincrona cu wsrep, eu dorm linistit.
Snapshot-urile de filesystem nu le faci pt backup, ci pt quick recovery, dupa care analizezi situatia si daca e necesar restaurezi backup
Eu personal fac 2 noduri de galera + arbitrator + un slave via wan pe care fac backup-urile

Salutare!

Pe mysql sau mariadb cu myisam hotcopy-ul este cred ca cel mai convenabil si sigur in cazul db-urilor mari.

Ex. 20 GB db cu hotcopy ai pot face restore in mai putin de 5 min., mai mult dureaza procezul de dezarhivare, 7z-ul care este foarte mancator … de orice…

Spor …
ps: pregatesc o varianta cu Percona sa vad diferentele

This utility is deprecated in MySQL 5.6.20 and removed in MySQL 5.7

Cu zfs poti face snapshot si recover in 2 secunde si nici nu omoara procesorul. Nu are rost sa arhivezi backup-urile recente, iar cele vechi le arhivezi cu LZMA (7zip), dar doar pe serverul de backup fiindca omoara procesorul si daca il limitezi poate te tine 10 ore pentru 20 gb.