înregistrare Logare
Puncte:1
avatar Server

Politica DNS pentru punctul final VPC

drapel za
Ralf

Am VPC cu trei subrețele în zone de disponibilitate diferite și un punct final VPC de interfață în fiecare. Punctul final VPC are 4 nume de gazdă DNS în mod implicit:

  • Un nume de gazdă DNS regional, de ex. vpce-x.ec2.us-east-1.vpce.amazonaws.com.
  • Trei nume de gazdă DNS zonale specifice punctului final, de ex. vpce-x-us-east-1a.ec2.us-east-1.vpce.amazonaws.com.

După cum am înțeles, numele de gazdă DNS regional va ajunge la un punct final arbitrar. Există o modalitate de a configura un singur nume de gazdă DNS care se va rezolva întotdeauna la punctul final din aceeași subrețea, pentru a reduce traficul inter-AZ? Nu sunt sigur dacă o politică de rutare cu latență este aplicabilă pentru acest caz de utilizare sau nu sau dacă există o altă soluție. Sau numele de gazdă DNS regional va face deja ceva de genul acesta?

Cazul de utilizare aici este o aplicație care trimite mult trafic către un serviciu extern prin punctele finale ale instanței VPC - până la punctul în care transferul de date implică costuri semnificative. Evitarea traficului inter-AZ pentru punctul final VPC ar reduce o parte din costurile de transfer de date.

44
0 + 0
Tim avatar
drapel gp
Tim
Ce încerci să obții? Ce problema ai?
0
Răspunde
drapel za
Ralf
Încercarea de a reduce costurile de transfer de date inter-AZ.
0
Răspunde
Tim avatar
drapel gp
Tim
Întrebarea ta este extrem de specifică fără a specifica imaginea de ansamblu, se întreabă despre soluția pe care o crezi că va funcționa. Vă sugerez să puneți o nouă întrebare care să vă sublinieze volumul de lucru, arhitectura dvs., care vă descrie problema (care ar putea include cât de mult trafic încrucișat AZ obțineți) și vă solicită sugestii. Soluția propusă de dvs. ar putea fi cea cu care vin oamenii, dar oamenii pot avea și alte idei. De exemplu, un ALB cu echilibrarea încărcăturii încrucișate dezactivat ar putea fi o soluție în anumite circumstanțe
0
Răspunde
drapel za
Ralf
S-au adăugat câteva detalii despre cazul de utilizare. Dar bănuiesc că răspunsul actual este calea de urmat aici, așa că nu voi posta altă întrebare. Utilizarea unui ALB (sau NLB) este o idee interesantă pentru aceasta, dar costurile ar fi apropiate de costurile de transfer de date inter-AZ.
0
Răspunde
Puncte:1
avatar Server
drapel cn
shearn89

Dacă utilizați numele DNS zonal, vorbiți cu zona respectivă. De la docs:

Alegeți o subrețea în VPC-ul dvs. pentru a utiliza punctul final al interfeței. Creăm o interfață de rețea endpoint în subrețea. Interfeței de rețea unui punct final i se atribuie o adresă IP privată din intervalul de adrese IP a subrețelei dvs. și păstrează această adresă IP până când punctul final al interfeței este șters. Puteți specifica mai mult de o subrețea în diferite zone de disponibilitate (așa cum este acceptată de serviciu) pentru a vă asigura că punctul final de interfață este rezistent la eșecurile zonei de disponibilitate. În acest caz, creăm o interfață de rețea endpoint în fiecare subrețea pe care o specificați.

Deci, dacă aveți o instanță care rulează de ex. us-east-1a, spuneți-i să folosească punctul final east-1a și toate comunicațiile vor fi în AZ. Ar trebui să puteți modifica numele DNS utilizând variabilele de mediu în codul dvs., mapările din CloudFormation sau căutările din Magazinul de parametri. Rețineți că acest lucru nu va fi rezistent la eșec.

Dacă nu faceți lucruri HPC care necesită o latență extrem de scăzută sau transferați cantități masive de date între zone, aș folosi doar numele regional (de exemplu, us-east-1).Așteptările mele ar fi că va folosi ceva sensibil.

Este posibil să puteți verifica făcând câteva gazdă REGIONALDNS și verificând ce IP îți dă înapoi și comparând cu rezultatul zonal.

0 + 0
drapel za
Ralf
Există suficiente date care trec prin punctul final încât costurile de trafic inter-AZ devin semnificative. Utilizarea directă a numelor DNS zonale ar rezolva problema, dar ar adăuga o oarecare complexitate serviciului (în prezent este același serviciu cu aceeași configurație implementată în mai multe AZ). Speram că există o modalitate simplă de a face asta cu Route53.
0
Răspunde
drapel cn
shearn89
Ați putea încerca să configurați ceva în R53 pentru a utiliza geoproximitatea sau rutarea latenței, dar nu este garantat - nu sunt sigur dacă geoproximitatea ar funcționa atât de aproape, iar latența este potențial variabilă în funcție de sarcină.
0
Răspunde
drapel za
Ralf
Utilizarea diferitelor nume de gazdă pentru diferitele AZ este probabil calea de urmat. Acest lucru poate fi făcut rezistent la eșec, preferând punctul final din același AZ și revenind la celelalte (de exemplu, înregistrări separate cu politică de rutare de failover).
0
Răspunde
drapel za
Ralf
Văd că politicile de rutare privind geoproximitatea și latența nu sunt disponibile pentru zonele private găzduite, așa că se pare că nu sunt concepute pentru acest caz de utilizare.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.