☰

간략한 답변

tag-icon • tag-icon azure-networking
간략한 답변

아래를 보면: 여기에 이미지 설명을 입력하세요

여기에는 단일 AZURE 회사 계정 X가 표시됩니다. "azsql1.database.windows.net"을 참조하세요. 온프레미스에서 액세스할 수 있습니다.

논쟁을 위해 두 번째 AZURE 환경이 있다면 어떨까요? 정확히 동일하게 구성되었습니다 - "azsql1.database.windows.net"을 사용하여 AZURE 회사 계정 Y.

이론적이지만 Tableau, Spotfire 등의 연결 보고서에 "azsql1.database.windows.net"을 사용하려고 하면 온프레미스에서 이 문제를 어떻게 해결하는지 알고 싶습니다.

어떤 방식으로든 어떤 AZURE 기업 계정에 사용할 DNS 전달자를 알려야 할 것 같습니다.

용서하세요. 하지만 저는 인터넷 bla bla bla의 기본적인 DNS 확인 내용을 이해하지만 네트워킹 전문가는 아닙니다.

답변1

같은 질문을 가진 다른 독자들을 위해: 다음도 참조하세요온프레미스에서 AZURE 리소스에 대한 개인 ipaddress에 액세스하는 데 사용되는 주소일부 배경 정보를 보려면.

귀하의 질문에 대한 약간의 수정에 답변하기 전에 "... 동일한 DNS 이름"이라고 썼습니다. 내 생각엔 이것이 오해라고 생각한다.Azure 코스모스 DB완전히 관리되는 서비스란PaaS따라서 고유한 이름이 있습니다. 즉, 두 개의 Azure Cosmos DB 서비스가 동일한 DNS 이름을 가질 수 없습니다. 그래도 나는 질문에서 그것을 수정하고 싶지 않지만 답변의 일부로 참조를 선호합니다. 이는 실제로 일반적인 오해이기 때문입니다. 이 모든 것은 하이브리드 솔루션의 이름 확인이 설계된 방식으로 요약됩니다.

이러한 시나리오를 해결하는 것은 고유한 DNS 이름(CosmosDB가 SaaS이고 고유한 이름이 있기 때문에 문제가 되지 않음)을 사용하고 모든 리소스를 확인할 수 있는지 확인하면 쉽습니다.

간략한 답변

ExpressRoute 또는 VPN을 통해 온-프레미스에 연결된 회사 계정의 각 구독에 대해Azure 프라이빗 DNS동일한 서브넷 내에 배포되는 DNS 전달자. 허브는 온프레미스를 포함한 모든 것을 연결합니다.

긴 답변

가상의 예(미션 정의)

작동 방식은 예를 사용하여 설명하는 것이 좋습니다.

가상의 기업을 고려하면 "NKOTBINC"에는 3개의 부서가 있습니다.

  • 재원
  • 그것
  • 마케팅

각 부서는 2개의 Azure 구독을 운영합니다. 하나는 개발용이고 다른 하나는 프로덕션 워크로드용입니다. 따라서 요구 사항을 충족하려면 총 6개 이상의 구독을 처리해야 합니다.

네트워크 관련 요구 사항은 다음과 같습니다.

  • 모든 구독은 온프레미스에 연결되어 있어야 합니다.
  • 모든 구독은 비공개 링크를 사용하여 배포된 리소스를 사용할 수도 있고 사용하지 않을 수도 있습니다.
  • 법적 제한으로 인해 모든 구독 내의 모든 리소스는 현재지역"미국 동부".
  • 향후 다른 지역을 활용해 사업을 확장할 계획이다. 따라서 계획 시 이를 고려해야 합니다.

구현 접근 방식

이 시나리오를 사용하면 최소 7개의 구독을 갖게 될 수 있습니다.

  • 개발 금융
  • PRD-파이낸스
  • 개발
  • PRD-IT
  • 개발 마케팅
  • 홍보 마케팅
  • 바퀴통VPN 또는 ExpressRoute를 통해 온프레미스에 연결됩니다.

6개 구독 모두 Azure 프라이빗 DNS와 DNS 전달자를 배포해야 합니다. 또한 이들 모두는 중앙 허브 구독에 피어링되는 VNET을 사용합니다. 따라서 결국에는 다음과 같은 7개의 내부 DNS 도메인이 생성됩니다.

  • 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
  • 허브.eastus.azure.nkotb

NKOTB inc - 높은 수준의 네트워크 연결 개요

허브 구독에는 두 번째 DNS 서버 및 전달자 세트가 구성되어 있습니다. 이 DNS 서버 집합만이 다른 도메인에 배포된 다른 7개의 DNS 전달자를 인식하고 "eastus.azure.nkotb" 도메인의 이름 확인을 담당합니다. 모든 온-프레미스 DNS 서버는 *.eastus.azure.nkotb에 대한 모든 DNS 요청을 이 DNS 서버 집합으로 전달하도록 구성됩니다.

예시 1: 구독과 온프레미스 간의 내부 DNS

재무 팀은 비공개 링크를 사용하여 프로덕션 구독 내에 "Alzheimer"라는 데이터베이스를 배포하기로 결정했습니다. 따라서 이 데이터베이스의 내부 DNS 이름(FQDN)은 alzheimer.prd.finance.eastus.azure.nkotb. 모든 구독과 온프레미스에 걸쳐 정렬되는 내부 이름 확인 덕분에 이 이름은 회사 네트워크 내의 모든 곳에서 확인할 수 있습니다.

예제 1의 작동 방식

  • 온프레미스에 위치한 임의의 클라이언트가 로컬 DNS 서버에 alzheimer.prd.finance.eastus.azure.nkotb.
  • 로컬 DNS 서버는 대답을 모르지만 *.eastus.azure.nkotb허브 구독 내에 배포된 DNS 전달자에 대한 모든 요청을 전달하도록 구성되어 있으므로 그렇게 합니다. 온-프레미스가 ExpressRoute/VPN을 통해 이 허브 구독에 연결되어 있으므로 이 DNS 서버는 네트워크 방식으로 연결할 수 있습니다.
  • 허브 구독 내에 배포된 DNS 전달자는 답변을 모르지만 프로덕션 금융 구독에 배포된 DNS 전달자를 알고 있으므로 요청이 이 방향으로 전달됩니다. 두 구독 모두 피어링된 VNET을 갖고 있으므로 이 DNS 서버는 네트워크 방식으로 연결할 수 있습니다.
  • prd.finance.eastus.azure.nkotb에 배포된 DNS 서버와 전달자는 데이터베이스의 IP 주소를 확인하고 응답을 체인으로 다시 보낼 수 있습니다.
  • 온프레미스에 위치한 클라이언트가 답변을 받습니다.
  • 각 후속 DNS 요청(기록의 TTL 내)은 답변이 캐시되었으므로 로컬 DNS 서버에서 즉시 응답됩니다.

예시 2: 2개 구독 간의 내부 DNS

마케팅 팀이 개발 구독 내에 "Ballyhoo"라는 데이터베이스를 배포하기로 결정한 경우 내부 DNS 이름은 ballyhoo.dev.marketing.eastus.azure.nkotb. 재무 부서에서 배포한 다른 데이터베이스와 마찬가지로 이 데이터베이스도 온프레미스에서 확인할 수 있습니다. 그러나 이 시나리오에서는 IT 팀이 IT 개발 구독 내에서 일부 데이터를 수집하며, 이는 ballyhoo.dev.marketing.eastus.azure.nkotb데이터베이스를 사용하여 저장해야 합니다. 따라서 이 시나리오에서는 2개의 구독 내에서 DNS 레코드를 확인하는 방법을 설명합니다.

예제 2의 작동 방식

  • dev-IT 구독에 배포된 데이터 수집 앱은 동일한 VNET 내에 배포된 로컬 DNS 확인자에게 ballyhoo.dev.marketing.eastus.azure.nkotb.
  • 로컬 DNS 서버는 대답을 모르지만 허브 구독 내에 배포된 DNS 전달자에 모든 요청을 전달하도록 구성되어 있으므로 그렇게 합니다. 두 구독 모두 피어링된 VNET을 갖고 있으므로 이 DNS 서버는 네트워크 방식으로 연결할 수 있습니다.
  • 허브 구독 내에 배포된 DNS 전달자는 답변을 모르지만 개발 마케팅 구독에 배포된 DNS 전달자를 알고 있으므로 요청이 이 방향으로 전달됩니다. 두 구독 모두 피어링된 VNET을 갖고 있으므로 이 DNS 서버는 네트워크 방식으로 연결할 수 있습니다.
  • dev.marketing.eastus.azure.nkotb에 배포된 DNS 서버와 전달자는 데이터베이스의 IP 주소를 확인하고 응답을 체인으로 다시 보낼 수 있습니다.
  • 데이터 수집 앱이 답변을 받습니다.
  • 각 후속 DNS 요청(기록의 TTL 내)은 답변이 캐시되었으므로 로컬 DNS 서버에서 즉시 응답됩니다.

노트

Azure의 비즈니스 담당자는 일반적으로 이러한 시나리오를 계획하는 데 도움이 되므로 모든 것을 직접 해결할 필요는 없습니다. 계획 과정에서 고려해야 할 다른 중요한 측면이 있지만 지면상 이러한 측면을 여기에 설명할 수는 없습니다. 깨달음: 일반적으로 네트워크 팀이 처음부터 프로세스에 포함되면 도움이 됩니다.

일반적으로 무료를 사용하는 것이 좋습니다.Azure용 Microsoft Learn필요한 지식과 기술을 쌓는 것입니다. 귀하의 질문에 대해서는 다음 과정이 적합할 것입니다:

관련 정보