Azure 'da Paylaşılan hizmetlerle hub-bağlı ağ topolojisiHub-spoke network topology with shared services in Azure

Bu başvuru mimarisi, hub 'a tüm bağlı bileşenler tarafından tüketilen paylaşılan hizmetleri eklemek için Merkez-uç başvuru mimarisi üzerinde oluşturulur.This reference architecture builds on the hub-spoke reference architecture to include shared services in the hub that can be consumed by all spokes.

Bir veri merkezini buluta geçirmeye yönelik ilk adım olarak, paylaşılması gereken ilk hizmetler kimlik ve güvenlik ' dir.As a first step toward migrating a datacenter to the cloud, the first services that need to be shared are identity and security. Bu başvuru mimarisi, şirket içi veri merkezinizden Azure 'a Active Directory Hizmetleri genişletmeyi ve güvenlik duvarı işlevi görecek bir ağ sanal gereci (NVA) eklemeyi gösterir.This reference architecture shows how to extend Active Directory services from your on-premises datacenter to Azure, and how to add a network virtual appliance (NVA) that can act as a firewall. Güvenlik Duvarı işlevselliği, bulut tabanlı bir ağ güvenlik hizmeti olan Azure Güvenlik Duvarıkullanılarak da gerçekleştirilebilir.The firewall functionality can also be accomplished using Azure Firewall, a cloud-based network security service.

Azure 'da paylaşılan hizmetler topolojisi

Bu mimarinin bir Visio dosyasını indirinDownload a Visio file of this architecture

Bu topolojinin avantajları şunlardır:The benefits of this topology include:

  • Maliyet tasarrufu: Ağ sanal gereçleri (NVA) ve DNS sunucuları gibi birden çok iş yükü tarafından paylaşılabilen hizmetler tek bir konumda merkezi hale getirilerek tasarruf sağlanır.Cost savings by centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location.
  • Abonelik sınırlarını aşma: Farklı aboneliklere ait sanal ağlar merkeze eşlenerek sınırlar aşılabilir.Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • İşlerin ayrılması: Merkezi BT (SecOps, InfraOps) ve iş yüklerini (DevOps) ilgilendiren konular ayrılır.Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

Bu mimarinin tipik kullanımları şunlardır:Typical uses for this architecture include:

  • Geliştirme, test ve üretim gibi farklı ortamlarda dağıtılan ve DNS, IDS, NTP veya AD DS gibi paylaşılan hizmetlere gerek duyan iş yükleri.Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Paylaşılan hizmetler merkezi sanal ağa yerleştirilir. Her bir ortam ise bir uca dağıtılarak yalıtım sağlanır.Shared services are placed in the hub VNet, while each environment is deployed to a spoke to maintain isolation.
  • Birbirlerine bağlı olmaları gerekmeyen ancak paylaşılan hizmetlere erişmeleri gereken iş yükleri.Workloads that do not require connectivity to each other, but require access to shared services.
  • Güvenlik konuları üzerinde merkezi denetime (merkezdeki bir güvenlik duvarı ile elde edilen bir DMZ gibi) ve her bir uçtaki iş yüklerinin ayrılmış bir şekilde yönetilmesine gerek duyan kurumlar.Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

MimariArchitecture

Mimari aşağıdaki bileşenlerden oluşur.The architecture consists of the following components.

  • Şirket içi ağ.On-premises network. Bir kuruluşun içinde çalışan özel bir yerel ağ.A private local-area network running within an organization.

  • VPN cihazı.VPN device. Şirket içi ağa dış bağlantı sağlayan bir cihaz veya hizmet.A device or service that provides external connectivity to the on-premises network. VPN cihazı, bir donanım cihazı veya Windows Server 2012’deki Yönlendirme ve Uzaktan Erişim Hizmeti (RRAS) gibi bir yazılım çözümü olabilir.The VPN device may be a hardware device, or a software solution such as the Routing and Remote Access Service (RRAS) in Windows Server 2012. Desteklenen VPN gereçlerinin listesini görmek ve Azure'a bağlanmak için belirli VPN gereçlerini yapılandırma hakkında bilgi edinmek istiyorsanız bkz. Siteden siteye VPN Gateway bağlantıları için VPN cihazları hakkında.For a list of supported VPN appliances and information on configuring selected VPN appliances for connecting to Azure, see About VPN devices for Site-to-Site VPN Gateway connections.

  • VPN sanal ağ geçidi veya ExpressRoute ağ geçidi.VPN virtual network gateway or ExpressRoute gateway. Sanal ağ geçidi, sanal ağın şirket içi ağınız ile bağlantı için kullanılan VPN cihazına veya ExpressRoute bağlantı hattına bağlanmasına olanak sağlar.The virtual network gateway enables the VNet to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. Daha fazla bilgi için bkz. Şirket içi bir ağı Microsoft Azure sanal ağına bağlama.For more information, see Connect an on-premises network to a Microsoft Azure virtual network.

Not

Bu başvuru mimarisine ait dağıtım betikleri, bağlantı için bir VPN ağ geçidi ve şirket içi ağınızın benzetimini yapmak için Azure’daki bir sanal ağı kullanmaktadır.The deployment scripts for this reference architecture use a VPN gateway for connectivity, and a VNet in Azure to simulate your on-premises network.

  • Merkezi sanal ağ.Hub VNet. Merkez-uç topolojisinde merkez olarak kullanılan Azure sanal ağı.Azure VNet used as the hub in the hub-spoke topology. Merkez, şirket içi ağınıza bağlantı için merkezi noktadır. Uç sanal ağlarında barındırılan farklı iş yükleri tarafından kullanılabilecek hizmetler burada barındırılır.The hub is the central point of connectivity to your on-premises network, and a place to host services that can be consumed by the different workloads hosted in the spoke VNets.

  • Ağ geçidi alt ağı.Gateway subnet. Sanal ağ geçitleri aynı alt ağda tutulur.The virtual network gateways are held in the same subnet.

  • Paylaşılan hizmetler alt ağı.Shared services subnet. DNS veya AD DS gibi tüm uçlar arasında paylaşılabilecek hizmetleri barındırmak için kullanılan merkez sanal ağdaki bir alt ağ.A subnet in the hub VNet used to host services that can be shared among all spokes, such as DNS or AD DS.

  • DMZ alt ağı.DMZ subnet. Hub VNet 'te güvenlik duvarları gibi güvenlik gereçlerini barındıraabilen NVA 'lar barındırmak için kullanılan bir alt ağ.A subnet in the hub VNet used to host NVAs that can act as security appliances, such as firewalls.

  • Uç sanal ağları.Spoke VNets. Merkez-uç topolojisinde uç olarak kullanılan bir veya daha fazla Azure sanal ağı.One or more Azure VNets that are used as spokes in the hub-spoke topology. Uçlar, iş yüklerini diğer uçlardan ayrı olarak yönetilen kendi sanal ağlarında yalıtmak için kullanılabilir.Spokes can be used to isolate workloads in their own VNets, managed separately from other spokes. Her iş yükü birden fazla katman içerebilir. Birden fazla alt ağ, Azure yük dengeleyicileri aracılığıyla birbirine bağlanır.Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. Uygulama altyapısı hakkında daha fazla bilgi için bkz. Windows VM iş yüklerini çalıştırma ve Linux VM iş yüklerini çalıştırma.For more information about the application infrastructure, see Running Windows VM workloads and Running Linux VM workloads.

  • VNET eşlemesi.VNet peering. İki sanal ağ, bir eşleme bağlantısıkullanılarak bağlanabilir.Two VNets can be connected using a peering connection. Eşleme bağlantıları, sanal ağlar arasındaki geçişsiz ve gecikme süresi düşük bağlantılardır.Peering connections are non-transitive, low latency connections between VNets. Sanal ağlar, eşlendikten sonra bir yönlendiriciye gerek kalmadan Azure omurgasını kullanarak aralarında bir trafik oluşturabilir.Once peered, the VNets exchange traffic by using the Azure backbone, without the need for a router. Merkez-uç ağ topolojisinde her ucu merkeze bağlamak için sanal ağ eşlemesi kullanılır.In a hub-spoke network topology, you use VNet peering to connect the hub to each spoke. Sanal ağları aynı bölgede veya farklı bölgelerde (genel VNet eşlemesi) eşleyebilir.You can peer virtual networks in the same region, or different regions (Global VNet Peering). Daha fazla bilgi için bkz. gereksinimler ve kısıtlamalar.For more information, see Requirements and constraints.

Not

Bu makalede yalnızca Resource Manager dağıtımlarından bahsedilmektedir. Ancak, aynı abonelikte klasik bir sanal ağı Resource Manager sanal ağına bağlamak da mümkündür.This article only covers Resource Manager deployments, but you can also connect a classic VNet to a Resource Manager VNet in the same subscription. Bu sayede, uçlarınız klasik dağıtımlar barındırıp aynı zamanda merkezde paylaşılan hizmetlerden de yararlanabilir.That way, your spokes can host classic deployments and still benefit from services shared in the hub.

ÖnerilerRecommendations

Hub-kol başvuru mimarisine yönelik tüm öneriler, paylaşılan hizmetler başvuru mimarisi için de geçerlidir.All the recommendations for the hub-spoke reference architecture also apply to the shared services reference architecture.

Ayrıca, aşağıdaki öneriler, paylaşılan hizmetler altındaki çoğu senaryo için geçerlidir.Also, the following recommendations apply for most scenarios under shared services. Bu önerileri geçersiz kılan belirli bir gereksiniminiz olmadığı sürece izlemeniz önerilir.Follow these recommendations unless you have a specific requirement that overrides them.

KimlikIdentity

Çoğu kuruluş kurumlarında, şirket içi veri merkezinde Active Directory Domain Services (AD DS) bir ortam vardır.Most enterprise organizations have an Active Directory Domain Services (AD DS) environment in their on-premises datacenter. AD DS bağlı olan şirket içi ağınızdan Azure 'a taşınan varlıkların yönetimini kolaylaştırmak için, Azure 'da AD DS etki alanı denetleyicileri barındırmanız önerilir.To facilitate management of assets moved to Azure from your on-premises network that depend on AD DS, it is recommended to host AD DS domain controllers in Azure.

Azure ve şirket içi ortamınız için ayrı olarak denetlemek istediğiniz grup ilkesi nesneleri kullanıyorsanız, her bir Azure bölgesi için farklı bir AD Sitesi kullanın.If you use Group Policy Objects, that you want to control separately for Azure and your on-premises environment, use a different AD site for each Azure region. Etki alanı denetleyicilerinizi, bağımlı iş yüklerinin erişebileceği bir merkezi VNet 'e (hub) yerleştirin.Place your domain controllers in a central VNet (hub) that dependent workloads can access.

GüvenlikSecurity

İş yüklerini şirket içi ortamınızdan Azure 'a taşırken, bu iş yüklerinden bazılarının VM 'lerde barındırılması gerekir.As you move workloads from your on-premises environment to Azure, some of these workloads will require to be hosted in VMs. Uyumluluk nedenleriyle, bu iş yüklerinden geçen trafikte kısıtlamalar uygulamanız gerekebilir.For compliance reasons, you may need to enforce restrictions on traffic traversing those workloads.

Azure 'da ağ sanal gereçlerini (NVA 'lar) kullanarak farklı türlerde güvenlik ve performans hizmetlerini barındırabilirsiniz.You can use network virtual appliances (NVAs) in Azure to host different types of security and performance services. Bugün şirket içi belirli bir gereçle ilgili bilgi sahibiyseniz, uygun yerlerde Azure 'da aynı sanallaştırılmış gereçler kullanılması önerilir.If you are familiar with a given set of appliances on-premises today, it is recommended to use the same virtualized appliances in Azure, where applicable.

Not

Bu başvuru mimarisine yönelik dağıtım betikleri, bir ağ sanal gerecini taklit etmek için IP iletimi etkinleştirilmiş bir Ubuntu VM kullanır.The deployment scripts for this reference architecture use an Ubuntu VM with IP forwarding enabled to mimic a network virtual appliance.

DevOps için dikkat edilmesi gerekenlerDevOps considerations

Bu başvuru mimarisi, hub-kol başvuru mimarisi üzerinde oluşturulur ve hub 'da tüm bağlı bileşenler tarafından tüketilen paylaşılan hizmetleri içerir. daha fazla bilgi için bu mimariye yönelik DevOps konularına bakın.This reference architecture builds on the hub-spoke reference architecture and includes shared services in the hub that can be consumed by all spokes, see the DevOps considerations on that architecture, for more information.

Maliyetle ilgili konularCost considerations

Bu başvuru mimarisi, hub-bağlı bileşen başvuru mimarisiüzerinde oluşturulur.This reference architecture builds on the hub-spoke reference architecture. Hub 'da tüm bağlı bileşen tarafından tüketilen paylaşılan hizmetleri içerir.It includes shared services in the hub that can be consumed by all spokes. Örneğin, birden çok iş yükü tarafından tüketilen bir paylaşılan hizmet olarak Active Directory Etki Alanı hizmetlerinin olması maliyet açısından etkilidir.For example, having Active Directory Domain services as a shared service consumed by multiple workloads is cost effective. Fiyatlandırma bilgileri için AD DS fiyatlandırmasına bakın.See AD DS pricing for pricing info.

Diğer maliyet konuları için bkz. hub-bağlı ağ topolojisi-maliyet konuları.For other cost considerations, see Hub-spoke network topology - cost considerations.

Çözümü dağıtmaDeploy the solution

Dikkat

"Azbb kullanmayın; BT, bu durumda ve NPM paketi güncel değil" olur."Don't use azbb - it is in sustain mode and the npm package is out of date". Alternatif olarak şunu kullanın: ARM şablonu: 101-hub-ve-bağlı-korumalı alanı veya Terkform kullanımı: Merkez-bağlı-girişAlternatively use: ARM Template: 101-hub-and-spoke-sandbox or use Terraform: hub-spoke-introduction

GitHub’da bu mimariye yönelik bir dağıtıma ulaşılabilir.A deployment for this architecture is available on GitHub. Dağıtım, aboneliğinizde aşağıdaki kaynak gruplarını oluşturur:The deployment creates the following resource groups in your subscription:

  • Merkez-ekler-RGhub-adds-rg
  • Merkez-NVA-RGhub-nva-rg
  • Hub-VNET-RGhub-vnet-rg
  • onprea-VNET-RGonprem-vnet-rg
  • spoke1-VNET-RGspoke1-vnet-rg
  • spoke2-VNET-RGspoke2-vnet-rg

Şablon parametre dosyaları bu adlara işaret eder. Bunları değiştirirseniz parametre dosyalarını bunlarla eşleşecek şekilde güncelleştirin.The template parameter files refer to these names, so if you change them, update the parameter files to match.

ÖnkoşullarPrerequisites

  1. Başvuru mimarileri GitHub deposuna ait zip dosyasını kopyalayın, indirin veya bu dosya için bir çatal oluşturun.Clone, fork, or download the zip file for the reference architectures GitHub repository.

  2. Azure CLI 2.0'ı yükleyin.Install Azure CLI 2.0.

  3. Node ve NPM'yi yükleyin.Install Node and NPM

  4. Azure yapı taşları npm paketini yükleyin.Install the Azure building blocks npm package.

    npm install -g @mspnp/azure-building-blocks
    
  5. Komut isteminden, bash isteminden veya PowerShell isteminden Azure hesabınızda aşağıda gösterildiği gibi oturum açın:From a command prompt, bash prompt, or PowerShell prompt, sign into your Azure account as follows:

    az login
    

Azbb kullanarak benzetimli şirket içi veri merkezini dağıtmaDeploy the simulated on-premises datacenter using azbb

Mimariyi dağıtmak için aşağıdaki adımları izleyin:Follow these steps to deploy the architecture:

  1. hybrid-networking\shared-services-stack\GitHub deposunun klasörüne gidin.Navigate to the hybrid-networking\shared-services-stack\ folder of the GitHub repository.

  2. shared-services-stack.json dosyasını açın.Open the shared-services-stack.json file.

  3. ,, Ve tüm örneklerini [replace-with-username] arayın [replace-with-safe-mode-username] [replace-with-password] [replace-with-safe-mode-password] .Search for all instances of [replace-with-username], [replace-with-safe-mode-username],[replace-with-password], and [replace-with-safe-mode-password]. Parametrelerde Kullanıcı adı ve parola değerlerini girin ve dosyayı kaydedin.Enter values for the user name and password in the parameters and save the file.

  4. Tüm örneklerini arayın [replace-with-shared-key] ve paylaşılan anahtar için bir değer girin.Search for all instances of [replace-with-shared-key] and enter a value for a shared key. Değerler eşleşmelidir.The values must match.

  5. Dosyayı kaydedin.Save the file.

  6. Şu komutu çalıştırın:Run the following command:

    azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p shared-services-stack.json --deploy
    
  7. Dağıtımın bitmesini bekleyin.Wait for the deployment to finish. Bu dağıtım, Active Directory etki alanı denetleyicileri, iki VPN ağ geçidi ve Azure Güvenlik duvarı olarak görev yapacak dört sanal makine olmak üzere dört sanal ağ, jumpkutular olarak işlev görecek dört sanal makine oluşturur.This deployment creates four virtual networks, four virtual machines to function as jumpboxes, four virtual machines to act as Active Directory domain controllers, two VPN Gateways, and Azure Firewall. VPN ağ geçidinin oluşturulması 40 dakikadan fazla sürebilir.The VPN gateway creation can take more than 40 minutes to complete.

Bağlantıyı test etmeTest connectivity

Benzetimli şirket içi ortamdan hub VNet 'e bağlantıyı test edin.Test connectivity from the simulated on-premises environment to the hub VNet.

  1. onprem-jb-rg kaynak grubunda jb-vm1 adlı bir sanal makine bulmak için Azure portalını kullanın.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Sanal makineye uzak masaüstü oturumu açmak için Connect öğesine tıklayın.Click Connect to open a remote desktop session to the VM. onprem.json parametre dosyasında belirttiğiniz parolayı kullanın.Use the password that you specified in the onprem.json parameter file.

  3. Sanal makinede bir PowerShell konsolu açın ve Test-NetConnection cmdlet 'ini kullanarak hub VNET 'teki sıçrama kutusu VM 'sine bağlanabildiğinizi doğrulayın.Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VM in the hub VNet.

    Test-NetConnection 10.0.0.36 -CommonTCPPort RDP
    

Çıktı aşağıdakine benzer görünmelidir:The output should look similar to the following:

ComputerName     : 10.0.0.36
RemoteAddress    : 10.0.0.36
RemotePort       : 3389
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.1.000
TcpTestSucceeded : True

Not

Varsayılan olarak, Windows Server VM 'Leri Azure 'da ıCMP yanıtlarına izin vermez.By default, Windows Server VMs do not allow ICMP responses in Azure. pingBağlantıyı sınamak için kullanmak istiyorsanız, her VM Için Windows Gelişmiş güvenlik DUVARıNDA ICMP trafiğini etkinleştirmeniz gerekir.If you want to use ping to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM.

Bağlı olan sanal ağlara yönelik bağlantıyı test etmek için aynı adımları yineleyin:Repeat the same steps to test connectivity to the spoke VNets:

Test-NetConnection 10.1.0.36 -CommonTCPPort RDP
Test-NetConnection 10.2.0.36 -CommonTCPPort RDP