Presupun ca te referi la acest configurarea DNS shopify.
Indicați A înregistrare la adresa IP Shopify 23.227.38.65.
Indicați CNAME înregistrarea cu numele www la magazine.myshopify.com
domeniu rădăcină (@)
După cum știți, nu puteți avea un CNAME pe rădăcină (@), deci domeniul rădăcină trebuie gestionat cu a A și aaaa înregistrări care indică către adrese IP fixe.
Modul în care marile companii extind acest lucru la nivel global utilizează „anycast” în care aceeași adresă IP este anunțată prin BGP din mai multe centre de date diferite.
Vă puteți gândi la anycast ca la echilibrarea încărcăturii gestionată de routere, unde mai multe servere din aceleași centre de date sau diferite pot primi și gestiona trafic pentru o singură adresă IP.
Dacă nu sunteți deja un AS cu propriul spațiu IP, atunci anycast este cu siguranță în afara domeniului dvs. de aplicare.
Modul simplu de a începe aici este să nu rulați nicio găzduire pe domeniul rădăcină, ci doar să faceți redirecționări către www. Apoi, o singură casetă de redirecționare nginx (sau multe în spatele unui echilibrator de încărcare level4/tcp) poate gestiona o mulțime de redirecționări de domeniu.
Dacă aveți nevoie de o mulțime de casete din cauza numărului mare de solicitări, utilizați echilibrarea încărcăturii tcp/layer4 pe serverele dvs. de redirector, astfel încât să puteți face terminarea aplicației (http) și ssl în casetele din spatele echilibratorului de încărcare pentru mai multă scalabilitate (echilibratorul de încărcare unic poate gestionează mai mult trafic).
Folosiți redirecționări permanente (301) care cache pe termen nelimitat reducerea traficului recurent de la aceiași clienți.
Cele mai bune practici aici. Utilizați letsencrypt/certbot pentru a genera automat/reînnoi domeniile de redirector odată ce DNS-ul este configurat. Redirecționați întotdeauna către https pe același domeniu (de exemplu. http://example.com --> https://example.com) înainte de a redirecționa către alt domeniu (https://www.example.com).
www
Mă uit la shopify magazine.myshopify.com (unde www CNAME ar trebui să punct) puteți vedea că are un singur A record care este în prezent 23.227.38.74.
Folosind un instrument global de ping puteți vedea că acest IP are câteva milisecunde de latență din multe locuri din lume. Aceasta înseamnă că cu siguranță nu este un singur server într-o singură locație (latența transatlantică rulează de obicei 60 ms în cel mai bun caz... deci când vedeți ping de 4 ms din SUA și UE pentru același IP... știți că acele ping-uri sunt" t merge la același server). De asemenea, puteți verifica acest lucru prin rularea unui traseu către aceeași IP de la servere diferite din zone geografice diferite.
La fiecare dintre punctele finale care răspund la acel IP, probabil că au un echilibrator de încărcare care direcționează cererile către hardware diferit.
Deci, în spatele CNAME shopify, este anycast cu un singur IP. Avantajul de a oferi clienților dvs. un CNAME este că aveți libertatea de a schimba IP-urile din spatele acelui nume, fără ca clienții să fie nevoiți să actualizeze DNS-ul. În această notă... când le oferi clienților tăi un A înregistrarea pentru rădăcina lor (@) redirector de domeniu... doriți să vă asigurați că aceasta este o adresă IP pe care o puteți controla și realoca unui hardware diferit dacă aveți probleme cu un server/echilibrator de încărcare (de exemplu, lucru de tip IP elastic AWS sau propriul spațiu IP dacă ești AS).
Din câte știu, nu există nici un „indiciu” dat cu privire la cererea DNS (și o parte din memoria cache a rezolutorului DNS) atunci când computerul urmărește lanțul CNAME atunci când rezolvă un nume pentru a spune serverului DNS final care este domeniul original. pe care l-ai cerut. Dacă ar exista, vă puteți imagina un server DNS având reguli condiționate pentru a returna adrese IP diferite pentru același nume, în funcție de numele care se află în spatele lui.
Deci, dacă nu o veți face în mod shopify (bgp/anycast). Cel mai simplu lucru ar fi să le oferi clienților tăi CNAME unice. În acest fel, puteți face echilibrarea încărcăturii la nivel DNS (returnând IP-uri diferite pentru fiecare CNAME unic de client).
Ai putea să urmezi o convenție cum ar fi customerdomain.tld.example.com și aveți DNS-ul furnizat automat pe baza bazei de date a activelor clienților.
Și pentru domeniul rădăcină (@) puteți utiliza în continuare un singur IP redirector (una sau mai multe casete în spatele unui singur IP/echilibrator de încărcare) gestionând redirecționarea pentru toate domeniile către www.customerdomain.tld la care CNAME-uri customerdomain.tld.example.com.
Actualizare... poate am ratat sensul întrebării dvs.
Acest lucru m-ar ajuta enorm atunci când trebuie să migrez o mulțime de site-uri web pe o nouă infrastructură
După cum am menționat mai sus, cel puțin pentru rădăcină/@ În caz contrar, TREBUIE să controlați acel IP și să îl puteți atribui altei infrastructuri... altfel toți clienții dvs. vor trebui să-și actualizeze DNS-ul atunci când acel IP se schimbă din cauza unei migrări.
Pentru www/CNAME În caz contrar, aceasta nu este o problemă, deoarece puteți actualiza IP-ul din spatele CNAME pe propriul DNS.
Deci mă voi concentra pe opțiunile doar pentru domeniul rădăcină (@), deoarece este cel mai problematic (necesită acțiunea clientului pentru a actualiza DNS atunci când adresa IP a serviciului lor se schimbă). Opțiuni...
opțiunea 0 - nu acceptă rădăcina/@ domeniu pentru clienți
Indiferent ce găzduiești, găzduiește-l pe un subdomeniu (www sau altul).
Dacă clienții doresc o redirecționare, ei pot gestiona asta cu oamenii lor IT.
Acest lucru elimină complet problema DNS-ului clientului care indică adresa IP fixă. Puteți actualiza adresele IP CNAME din partea dvs. și orice mutare a infrastructurii sau schimbare a IP devine simplă.
opțiunea 1 - adrese IP atribuibile
Puteți folosi lucruri precum adrese IP atribuibile (chestia cu tipul de ip elastic AWS, cei mai serioși furnizori de VPS oferă ceva similar).
Acest lucru vă permite să implementați un nou server (la acel furnizor) și apoi să comutați IP-ul pe noul server.
Problema este că aveți blocarea furnizorului/furnizorului, deoarece adresele IP aparțin furnizorului. Deci, dacă doriți să treceți de la AWS la Google-Cloud sau propriul hardware, nu puteți lua acele IP-uri cu dvs.... Actualizare DNS pentru clienții dvs. De asemenea, IP-urile pot fi blocate în regiune, astfel încât să nu puteți atribui cu ușurință IP-ul unui alt server de la furnizor într-un alt centru de date.
opțiunea 2 - deveniți un AS și obțineți propriul spațiu IP
Dacă faci găzduire serioasă, este doar o chestiune de timp până când trebuie să devii AS (Sistem autonom) prin intermediul ARIN sau COPT sau o altă organizație dacă compania dvs. se află în afara Americii de Nord și a Europei.
Apoi, trebuie să achiziționați (sau să închiriați) propriul bloc de adrese IP. Puteți obține ipv6 gratuit de obicei. ipv4 s-a epuizat, dar cel puțin RIPE vă permite să intrați pe o listă de așteptare pentru a /24 (256 de adrese) când le recuperează în timp. În caz contrar, trebuie să cumpărați spațiul de adresă de la cineva (există piețe la care vă puteți înscrie).
Și, desigur, atunci trebuie să lucrați cu furnizori care vă permit să aduceți propriile adrese IP.
Iată câteva link-uri practice care parcurg o configurație anycast. Dar, pentru început, ignorați biții anycast și concentrați-vă pe configurarea ca AS, obținerea spațiului IP și găsirea tipului potrivit de parteneri infra. (Deoarece rularea BGP/anycast nu este banală.)
Dezavantaje:
- investiție de timp pentru a configura lucrurile și a învăța (de exemplu, BGP dacă furnizorul dvs. din amonte nu se ocupă de asta pentru dvs.).
- investiții financiare (taxe de membru/IP pentru RIPE/ARIN și costuri potențial mari pentru achiziționarea/închirierea blocurilor IPv4).
- limitat la lucrul cu furnizorii VPS care vă permit să vă aduceți propriile IP-uri
- Sau trebuie să închiriați spațiu în rack și să vă ocupați de peering/routing/switching/BGP/etc, defecțiuni hardware, monitorizare hardware SNMP etc.
- noi distrageri de atenție, cum ar fi nevoia de a contracara și a adresa plângeri de abuz legate de spațiul dvs. IP
Cu siguranță are sens la o anumită scară sau dacă aveți deja abilitățile și instrumentele necesare pentru a o gestiona.
opțiunea 3 - DNS nestandard
Unii furnizori de DNS gestionați au adăugat CNAME-cum ar fi suport pentru domeniul naked/root.
Dacă utilizați unul dintre acești furnizori sau implementați singur acest lucru dacă rulați propriul DNS... atunci asta poate rezolva problema.
Vezi acest răspuns
Dacă te bazezi pe acest lucru, atunci ești blocat de furnizor la furnizorii DNS care acceptă această caracteristică non-standard. Sau trebuie să rulați propriul DNS și să implementați acest lucru singur.
opțiunea 4 - CDN
În funcție de aplicația dvs., puteți pune un alt serviciu în fața acesteia. adică serviciu asemănător CDN (stackpath, cloudflare, aws-cloudfront etc). Acești băieți se vor ocupa de DNS/anycast și de subiecte conexe, iar clienții tăi se vor îndrepta către serviciul CDN și vor rula serviciile în spatele CDN-ului.
Schimbarea serviciilor back-end devin modificări de configurare la CDN (sau similar) pentru a spune CDN-ului numele/ip-urile punctelor finale de la care ar trebui să fie solicitat conținutul.
Dezavantaje:
- cost suplimentar dacă nu aveți nevoie.
- trebuie să vă asigurați că punctele finale stocate în cache versus non-cache (de exemplu, aplicația) sunt configurate pe CDN pentru a se potrivi cu modul în care funcționează aplicația(ele) dvs.
- strat suplimentar care trebuie depanat dacă aplicația dvs. nu funcționează (CDN-ul a întrerupt solicitarea sau aplicația dvs.?).
- de obicei, aceasta înseamnă că înregistrarea CNAME a clientului dvs. va indica domeniul CDN-ului... nu al dvs. Domeniul dvs. se află în configurația aplicației CDN ca server upstream. Deci, aveți blocarea furnizorului... dacă doriți să schimbați CDN-urile, toți clienții dvs. vor trebui să-și actualizeze CNAME-urile DNS pentru a indica cel nou. Puteți atenua acest lucru punând 2 straturi de CNAME (client -> dvs. -> CDN), dar asta nu este grozav dintr-un perspectiva performanței.
ce aș face
Fără mai multe detalii despre dimensiunea bazei dvs. de clienți, abilitățile (de exemplu, BGP), dacă utilizați propriul hardware sau închiriați VPS ieftin...
Îmi place simplu, îl poți face oricând mai complex mai târziu. Care este cel mai simplu lucru care îmi menține costurile scăzute, nu necesită mult timp, oferă o experiență bună de utilizare pentru clienții mei și, în cele din urmă, îmi permite să mă întorc la activități generatoare de venituri (în loc să petrec timp pe un backend tehnic care are un cost de timp/financiar cu speranța de a reduce costurile totale la scară). Nu sunt google, așa că prefer să-mi cresc linia de sus decât să-mi micro-optimizez rezultatul... mai ales dacă nu există o nevoie tehnică (încă).
as face urmatoarele...
- nu există suport pentru domeniul naked/root al clienților. clienții care doresc o redirecționare pot avea personalul IT să o configureze. O durere de cap mai mare.
- Sau dacă doriți să susțineți acest lucru, configurați un singur IP redirector pe care știți că nu îl veți pierde (de exemplu, AWS elastic IP) și configurați clienții
A și aaaa înregistrări. Restul serviciilor dvs. nu trebuie să fie găzduite în același loc (adică redirectorul poate fi AWS cu ELB dacă trebuie să scalați redirecționarea, iar casetele pentru clienți pot fi pe VPS-uri ieftine).
- fiecare client primește un CNAME previzibil (unic pentru el) pe baza domeniului găzduit sau a ID-ului de client (
CUS1234.example.com are mai mult sens dacă oferiți clienților posibilitatea de a schimba cu ușurință domeniul pe care îl găzduiesc).
- DNS-ul meu este actualizat automat pe baza bazei de date a clienților (domeniile clienților -> CNAME specific clientului -> adresa IP care găzduiește aplicația clientului).
- Pot monitoriza cu ușurință DNS-ul clientului respectiv, iar DNS-urile mele sunt toate îndreptate către locul potrivit.
- Pot monitoriza traficul/abuzul DNS pe bază de client separat (pentru că au nume unice) de la punctul final al clientului.
Clienții își setează DNS-ul o dată și nu trebuie să-l modifice decât dacă doresc să-și schimbe domeniul găzduit.
Migrările infrastructurii sunt relativ ușoare dacă aveți mecanisme bune de backup/restaurare/replicare care funcționează în tandem cu o anumită formă de descoperire a serviciului pe stratul de furnizare a serverului/vps/aplicației.
- setați un TTL DNS scăzut în înregistrările dvs. DNS (adică numele către care indică CNAME al clientului
CUST1234.example.com A 10.0.0.1) cu ceva timp înainte de migrare.
- Învârtiți noi infrastructuri, inclusiv replicarea datelor din infra vechi (baze de date, conținut încărcat de utilizator etc.).
- Schimbați înregistrările DNS ale clienților (
A, aaaa) pentru a indica noile IP-uri
- Eliminați vechea infrastructură după ce s-a scurs marginea DNS TTL +.
Dacă backend-ul dvs. de date nu poate gestiona scrierile de la 2 puncte finale ale clienților activi în același timp, atunci este posibil să fie nevoie să aveți o întrerupere pentru migrare... deoarece va exista o suprapunere pe măsură ce vechiul cache DNS expiră.
Avantajul acestui tip de configurare este că pot rula pe aproape orice furnizor de VPS de renume pe care îl doresc (provizionarea mea automată nu este pretențioasă). Nu trebuie să fac investiția pentru a deveni un AS și să mă ocup de cheltuielile suplimentare legate de gestionarea propriului spațiu IP (cu siguranță are sens să fac asta la o anumită scară... dar nu cunosc situația companiei dvs.) .
Pot face lucruri precum echilibrarea încărcării geografice bazată pe DNS (return IP diferit pentru același nume, în funcție de regiunea serverului solicitant). Acest lucru vă permite să oferiți unui client mai multe servere sub același nume în regiuni diferite (astfel încât să nu aibă de-a face cu latența trans-SUA sau trans-atlantică atunci când încarcă o aplicație). Puteți oferi acest lucru pe bază de client ca valoare adăugată/upsell.
Notă despre echilibrarea sarcinii...
Am menționat de mai multe ori echilibrarea încărcăturii tcp/layer4 fără a detalia. În general, aveți două tipuri comune de echilibrare a sarcinii. layer4/transport/tcp și layer7/application/http(s).
Un echilibrator de încărcare layer7/application/http „vorbește” http și termină conexiunea ssl înainte de a trimite cererea (de obicei, http necriptată) către unul dintre multiplele servere din spatele echilibrerului/proxy-ului. Acest lucru este simplu, dar poate duce la probleme în care serverele din spatele echilibratorului de încărcare nu știu că ar trebui să pretindă că vorbesc https atunci când scriu anteturi, cookie-uri securizate, redirecționări etc. Înseamnă, de asemenea, că echilibratorul de încărcare trebuie să lucreze mai mult. per cerere (parsarea http și gestionarea overhead SSL). Această muncă suplimentară limitează scalabilitatea echilibratorului de încărcare, care este de obicei un singur nod/mașină/vps.
Un echilibrator de încărcare layer4/tcp nu trebuie să analizeze cererea http sau să aibă suprasarcina de terminare SSL. Nu știe nimic despre http. Solicitarea este direcționată către unul dintre multiplele servere care se ocupă de terminarea ssl și gestionează cererea http.
Dacă sunteți îngrijorat de reutilizarea (sau lipsa) sesiunii TLS care afectează performanța, este obișnuit să utilizați redis sau memcached ca cache de sesiune TLS partajată între mai multe servere web, astfel încât să nu vă faceți griji că echilibratorul de încărcare va menține utilizatorii „lipiciți” la o casetă specifică în spatele echilibratorului de sarcină. nginx nu pare să accepte memoria cache a sesiunii TLS off-box (cache-ul partajat doar între lucrătorii nginx din aceeași casetă). haproxy pare să aibă ceva dar nu l-am încercat și nu știu cum ar funcționa în haproxy/level4 în fața unui pool nginx unde are loc terminarea ssl.
Puteți utiliza nginx sau haproxy ca echilibrator de încărcare layer4/tcp, ambele sunt destul de simple de configurat. Pentru cazuri de utilizare mai avansate (și probabil o performanță mai bună) vă puteți uita și la Linux Virtual Server (LVS).
Un alt mod de distribuire a încărcăturii este de a avea mai multe înregistrări A sau AAAA returnate pentru un singur nume. În mod ideal, clientul DNS alege aleatoriu dintre adresele returnate, astfel încât să obțineți o anumită distribuție a încărcării pe mai multe adrese IP. Dacă începeți să întâmpinați probleme de scalare cu nivelul de echilibrare a încărcăturii, aceasta este o modalitate low-tech de a adăuga mai multă scară (doar adăugați un alt echilibrator de încărcare față de același grup de servere de aplicații sau diferit). Cu toate acestea, nimic nu îi obligă pe clienți să-ți rotunjească adresele IP... deci acest lucru nu vă oferă prea mult control asupra IP-urilor care primesc încărcarea... dar este mai bine decât nimic.
