Conectare optima pentru conexiunea dintre servere din locatii diferite

Salutari,

Am nevoie de un sfat din partea voastra, va rog.

Avem 3 servere in 3 locatii diferite.

SRV1 din locatia A ruleaza Windows Server sau Windows 10. Pe acest server se afla o aplicatie care comunica prin input xml → output xml

SRV2 si SRV3 din locatiile B si C, care ruleaza Linux, trebuie sa trimita input xml la SRV1 si sa primeasca output xml de la SRV1. SRV2 si SRV3 sunt niste aplicatii web care folosesc output-ul de la SRV1.

  1. Care este cea mai buna varianta de a face transferul acesta de fisiere xml?
  2. Ce alte lucruri trebuie sa mai am in vedere pentru acest setup?

Multumesc!

diagram

Un server web care accepta prin POST fișiere input XML și răspunde cu output XML.

Ar mai fi detalii despre cît durează procesare fișierelor input, normal ar fi să le pui într-o coadă de execuție. Dar depinde de cîte cereri poți avea simultan și cît durează fiecare din ele.

Ar mai fi și partea de securizare/autorizare dacă serverele sînt connectete prin Internet în loc de VPN.

3 Likes

Multumesc, Cornel.

Da, va exista o coada de asteptare si o limitare a input-ului pentru ca procesarea poate dura la infinit…

Pana o sa ajung sa testez, aveti vreo idee cat de limitativ poate fi faptul ca SRV1 va fi intotdeauna in Romania, in timp ce SRV2 si SRV3 vor fi in cloud prin US si EU? Nu se astepta ca pe SRV2 si SRV3 sa fie raspunsuri instant. In momentul acesta, fara sa fiu foarte priceput, ma gandesc ca atat timp cat intre servere se transfera doar fisiere XML, totul va depinde de marimea fisierelor si latimea de banda. O fi corect ce zic? :thinking:

N-ar trebui să fie o problemă.

Poți trimite xml-urile gata arhivate/comprimate ca să faci transferul mai rapid.

Ar trebui să iei în calcul și varianta în care SRV1 devine indisponibil.

Eu pentru o aplicaţie de acest gen (pe un server se fac plaţile cu cardul, pe alt server se emit facturile pentru acele plăţi) folosesc două servere de email. Ala care primeşte plata crează un JSON cuu detaliile de facturat şi trimite prin email către cel care facturează. Pe cel care facturează este un script pentru postfix care ia ataşamentul cu JSON şi face ce trebuie cu el.

De ce am ales varianta cu email? Pentru că în caz de cădere a conexiunii, postfix-ul vă reîncerca cu încăpăţânare să livreze acel mesaj, până reuşeşte. Altfel ar fi trebuit eu să-mi bat capul cu un sistem de retry şi nu e deloc simplu să faci unul reliable.

3 Likes

F. mișto ideea. Dar nu e greu de implementat un mecanism de retry.

Dacă dă eroare, pui fișierul XML într-o coadă de retry (un tabel într-o bază de date pe pe SRV2/3, sqlite să zicem și un timestamp cînd să încerce data viitoare now + 1min, de exemplu).

Apoi dintr-un cron execuți un script odată la 1-2 minute care încearcă iar să trimită fișierul.
Dacă reușește, șterge intrarea din coadă (sau o marchează ca fiind procesat(ă)), dacă nu, incrementezi timestampul cu 150 de secunde, de exemplu.

Alte variante:

  • ftp upload
  • AWS SQS
  • RabbitMQ as a Service

Xml ? Of of, urasc xml-ul cand e vorba de comunicat date intre servere. 10% date si 90% taguri.

4 Likes

Și eu am alergie la XML de pe vremea când deschidea IE6 un XML de 1MB in vreo 10 secunde (le baga fain in tree și noi doar voiam să ne belim ochii la el mai ușor). Cea mai ratata decizie posibilă a fost sa facem niste rapoarte HTML (deși putea fi și alt format) băgând din DB in XML apoi prin XSLT.

Da’ Moore le rezolva pe toate. Că doar și hello world in Java lua 3 secunde sa ruleze pe 486 și uite că e the enterprise shit și bancile-s pe spate (că sa fim corecți și JVM a miscat, și design patterns și multe chestii faine au venit pe ruta ratatului de Java :D).

Despre ce vorbeam? :smiley:

Din Romania în SUA, de exemplu, ai o latenta de rețea de de 100-200ms in funcție de coastă. Și atunci nu prea contează asta când tu ai procesari lungi (ai zis “infinit”). Ce contează în schimb e că poate fi unreliable (cu o probabilitate mai mare decât pe distante mici, dar nu catastrofal).

Și atunci trebuie sa urmărești 2 chestii (oricum era bine să le faci și dacă erai în LAN, e un model mai robust):

  1. asincron, deci folosești o coada gen RabbitMQ
  2. Să ai cod robust la trimitere și primire, adică să confirme că s-a finalizat operația sau sa reincerce după x secunde random. Zicea un coleg de o un mini sistem banal de retry: tii într-un director fișiere de trimis, când a confirmat trimiterea șterge fișierul, daca nu e șters reîncearcă la next run (un cron sau ceva).

Poți face un micro serviciu într-un ecran cred (in Python cu Flask sau ce o fi) care face o singura chestie: primește fișierul pe un POST și îl bagă în coadă. Atât. Ai grija sa ai pe server și client HTTP gzip sau brotli și ai rezolvat și compresia mizeriei xml (care va fi foarte eficienta la vorbărețul asta ratat).

Separat ai modulul ce face procesare și ia din coada și pune rezultatul pe alte coada.

1 Like