Pentru alți cititori cu aceeași întrebare: Vezi și Adresă care va fi folosită pentru a accesa adresa IP privată pentru resursa AZURE din local pentru câteva informații de fundal.
Înainte de a începe să răspund la o mică corecție la întrebarea dvs., așa cum ați scris „... același nume DNS”. Cred că aceasta este o neînțelegere, deoarece Azure Cosmos DB este un serviciu complet gestionat, înseamnă PaaS și ca atare are nume unice. Cu alte cuvinte, este imposibil ca două servicii Azure Cosmos DB să aibă același nume DNS. Totuși, nu vreau să corectez asta în întrebare, dar prefer referința ca parte a răspunsului, deoarece aceasta este într-adevăr o neînțelegere comună. Totul se rezumă la modul în care este proiectată rezoluția de nume a unei soluții hibride.
Rezolvarea unui astfel de scenariu este ușoară, folosind nume DNS unice (ceea ce nu este o problemă deoarece CosmosDB este SaaS și, ca atare, are nume unice) și pentru a vă asigura că toate resursele pot fi rezolvate.
Răspuns scurt
Pentru fiecare dintre abonamentele dvs. din contul corporativ conectat la local prin ExpressRoute sau VPN, configurați a Azure DNS privat și un forwarder DNS, care este implementat în aceeași subrețea. Un hub conectează totul, inclusiv on-premise.
Raspuns lung
Exemplu ipotetic (definiția misiunii)
Cum funcționează este mai bine să explicați folosind un exemplu.
Având în vedere ipotetica corporație "NKOTB INC" are 3 departamente:
- Finanţa
- ACEASTA
- Marketing
Fiecare departament operează 2 abonamente Azure, unul pentru dezvoltare, celălalt pentru volumul de lucru de producție. Așa că trebuie să ne ocupăm de cel puțin șase abonamente în total, pentru a îndeplini cerințele.
Cerințele legate de rețea sunt următoarele:
- Fiecare abonament trebuie să aibă conectivitate la local.
- Fiecare abonament poate folosi sau nu resurse care sunt implementate folosind link-uri private.
- Din cauza restricțiilor legale, toate resursele din toate abonamentele sunt implementate în prezent regiune „Estul SUA”.
- Este planificată extinderea afacerii, utilizând eventual alte regiuni. Prin urmare, acest lucru ar trebui luat în considerare în planificare.
Abordarea implementării
Folosind acest scenariu, puteți ajunge cu cel puțin 7 abonamente:
- dev-finance
- prd-finanţe
- dev-it
- prd-it
- dev-marketing
- prd-marketing
- Hub care se conectează la local prin VPN sau ExpressRoute.
Toate cele șase abonamente trebuie să implementeze un DNS privat Azure și un forwarder DNS. În plus, toți folosesc un VNET care este conectat la abonamentul central Hub. Deci, în cele din urmă, veți ajunge cu aceste șapte domenii DNS interne:
- dev.finance.eastus.azure.nkotb
- prd.finance.eastus.azure.nkotb
- dev.it.eastus.azure.nkotb
- prd.it.eastus.azure.nkotb
- dev.marketing.eastus.azure.nkotb
- prd.marketing.eastus.azure.nkotb
- hub.eastus.azure.nkotb
Abonamentul Hub are un al doilea set de servere DNS și redirecționare configurate. Numai acest set de servere DNS este conștient de ceilalți șapte forwarder DNS implementați în celelalte domenii și responsabil pentru rezolvarea numelor domeniului „eastus.azure.nkotb”. Toate serverele DNS locale sunt configurate pentru a redirecționa toate solicitările DNS pentru *.eastus.azure.nkotb către acest set de servere DNS.
Exemplul 1: DNS intern între un abonament și on premise
Având în vedere că echipa financiară decide să implementeze o bază de date numită „Alzheimer” în cadrul abonamentului de producție, folosind un link privat. Deci, numele DNS intern (FQDN) pentru această bază de date ar fi alzheimer.prd.finance.eastus.azure.nkotb.
Datorită rezoluției interne a numelui, care este aliniată la toate abonamentele și, de asemenea, la nivel local, acest nume poate fi rezolvat peste tot în rețeaua corporativă.
Cum funcționează Exemplul 1
- Un client aleatoriu situat la locație cere serverului DNS local să rezolve
alzheimer.prd.finance.eastus.azure.nkotb.
- Serverul DNS local nu știe răspunsul, dar este configurat să redirecționeze toate solicitările pentru
*.eastus.azure.nkotb către expeditorul DNS implementat în cadrul abonamentului Hub, așa că face. Acest server DNS este accesibil (din rețea), deoarece local este conectat la acest abonament hub prin ExpressRoute/VPN.
- Redirecționerul DNS implementat în cadrul abonamentului hub nu cunoaște răspunsul, dar este conștient de forwarder-ul DNS care este implementat în abonamentul de finanțare a producției, deci cererea este transmisă în această direcție. Acest server DNS este accesibil (din punct de vedere al rețelei), deoarece ambele abonamente au peered VNET-uri.
- Serverul DNS și forwarderul implementate în prd.finance.eastus.azure.nkotb pot rezolva adresa IP a bazei de date și trimite răspunsul înapoi în lanț.
- Clientul situat la sediul primește răspunsul.
- Fiecare cerere DNS ulterioară (în TTL-ul înregistrării) va primi imediat răspuns de la serverul DNS local, deoarece răspunsul a fost stocat în cache.
Exemplul 2: DNS intern între 2 abonamente
Având în vedere că echipa de marketing decide să implementeze o bază de date numită „Ballyhoo” în cadrul abonamentului pentru dezvoltatori, astfel încât numele DNS intern ar fi ballyhoo.dev.marketing.eastus.azure.nkotb. La fel ca cealaltă bază de date implementată de finanțe, această bază de date poate fi rezolvată și din local. Dar, în acest scenariu, echipa IT colectează unele date în cadrul abonamentului IT dev, care ar trebui să fie stocate folosind ballyhoo.dev.marketing.eastus.azure.nkotb Bază de date. Deci, acest scenariu descrie modul în care o înregistrare DNS poate fi rezolvată în 2 abonamente.
Cum funcționează Exemplul 2
- Aplicația de colectare a datelor implementată în abonamentul dev-IT solicită soluției DNS local implementate în același VNET adresa IP a
ballyhoo.dev.marketing.eastus.azure.nkotb.
- Serverul DNS local nu știe răspunsul, dar este configurat să redirecționeze toate cererile către redirecționerul DNS implementat în cadrul abonamentului Hub, așa că o face. Acest server DNS este accesibil (din punct de vedere al rețelei), deoarece ambele abonamente au peered VNET-uri.
- Redirecționerul DNS implementat în cadrul abonamentului hub nu cunoaște răspunsul, dar este conștient de redirecționarul DNS care este implementat în abonamentul de marketing pentru dezvoltatori, deci cererea este redirecționată în această direcție.Acest server DNS este accesibil (din punct de vedere al rețelei), deoarece ambele abonamente au peered VNET-uri.
- Serverul DNS și forwarderul implementate în dev.marketing.eastus.azure.nkotb pot rezolva adresa IP a bazei de date și trimite răspunsul înapoi în lanț.
- Aplicația de colectare a datelor primește răspunsul.
- Fiecare cerere DNS ulterioară (în TTL-ul înregistrării) va primi imediat răspuns de la serverul DNS local, deoarece răspunsul a fost stocat în cache.
Note
Contactul dvs. de afaceri din Azure vă ajută, de obicei, să planificați astfel de scenarii, astfel încât nu trebuie să rezolvați totul singur. Există și alte aspecte importante de luat în considerare în timpul procesului de planificare, dar spațiul nu permite să fie conturate aici. Realizare: De obicei ajută dacă echipa rețelei este inclusă în proces încă de la început.
În general, recomand cu căldură să utilizați gratuit Microsoft Learn pentru Azure pentru a construi cunoștințele și abilitățile necesare. Pentru întrebările dvs., următoarele cursuri ar fi adecvate:
