Windows N szintű alkalmazás Azure Stack hub-on SQL ServerWindows N-tier application on Azure Stack Hub with SQL Server

Ez a hivatkozási architektúra bemutatja, hogyan helyezhet üzembe virtuális gépeket (VM) és egy N szintű alkalmazáshoz konfigurált virtuális hálózatot az adatrétegen a Windows SQL Server használatával.This reference architecture shows how to deploy virtual machines (VMs) and a virtual network configured for an N-tier application, using SQL Server on Windows for the data tier.

ArchitektúraArchitecture

Az architektúra a következő összetevőket tartalmazza.The architecture has the following components.

A diagram egy olyan virtuális hálózatot mutat be, amely hat alhálózatot tartalmaz: Application Gateway, felügyelet, webes réteg, üzleti réteg, adatréteg és Active Directory.

Általános kérdésekGeneral

  • Erőforráscsoport.Resource group. Az erőforráscsoportok az Azure-erőforrások csoportosítására használhatók, így élettartamuk, tulajdonosuk vagy egyéb feltételek szerint kezelhetők.Resource groups are used to group Azure resources so they can be managed by lifetime, owner, or other criteria.

  • Rendelkezésre állási csoport.Availability Set. A rendelkezésre állási csoport egy adatközpont-konfiguráció, amely a virtuális gépek redundanciát és rendelkezésre állását biztosítja.Availability set is a datacenter configuration to provide VM redundancy and availability. A Azure Stack hub-bélyegzőn belüli konfiguráció biztosítja, hogy a tervezett vagy nem tervezett karbantartási események során legalább egy virtuális gép elérhető legyen.This configuration within an Azure Stack Hub stamp ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available. A virtuális gépek olyan rendelkezésre állási csoportba kerülnek, amely több tartalék tartományba (Azure Stack hub gazdagépre) terjed ki.VMs are placed in an availability set that spreads them across multiple fault domains (Azure Stack Hub hosts)

Hálózatkezelés és terheléselosztásNetworking and load balancing

  • Virtuális hálózat és alhálózatok.Virtual network and subnets. Minden Azure-beli virtuális gép üzembe helyezése egy, az alhálózatokra szegmentált virtuális hálózatba történik.Every Azure VM is deployed into a virtual network that can be segmented into subnets. Hozzon létre egy külön alhálózatot minden egyes szinthez.Create a separate subnet for each tier.

  • 7. rétegbeli Load Balancer.Layer 7 Load Balancer. Mivel a Application Gateway még nem érhető el az Azure stack hub-on, a Azure stack hub piacon elérhető alternatívák is rendelkezésre állnak, például: Kemp Loadmaster Load Balancer ADC Content Switch / F5 Big-IP Virtual Edition vagy A10 vThunder ADCAs Application Gateway is not yet available on Azure Stack Hub, there are alternatives available on Azure Stack Hub Market place such as: KEMP LoadMaster Load Balancer ADC Content Switch/ f5 Big-IP Virtual Edition or A10 vThunder ADC

  • Terheléselosztó.Load balancers. A Azure Load Balancer használatával terjesztheti a webes szinten lévő hálózati forgalmat az üzleti szintjére, valamint az üzleti szintjétől a SQL Serverig.Use Azure Load Balancer to distribute network traffic from the web tier to the business tier, and from the business tier to SQL Server.

  • Hálózati biztonsági csoportok (NSG).Network security groups (NSGs). A NSG használata a virtuális hálózaton belüli hálózati forgalom korlátozására.Use NSGs to restrict network traffic within the virtual network. Az itt látható háromrétegű architektúrában például az adatbázis-réteg nem fogadja el a webes kezelőfelületről érkező forgalmat, csak az üzleti rétegből és a felügyeleti alhálózatból.For example, in the three-tier architecture shown here, the database tier does not accept traffic from the web front end, only from the business tier and the management subnet.

  • DNS.DNS. Azure Stack hub nem biztosítja a saját DNS-üzemeltetési szolgáltatását, ezért használja a DNS-kiszolgálót a HOZZÁADÁShoz.Azure Stack Hub does not provide its own DNS hosting service, so please use the DNS server in your ADDS.

Virtuális gépekVirtual machines

  • SQL Server always on rendelkezésre állási csoport.SQL Server Always On Availability Group. Magas rendelkezésre állást biztosít az adatszinten a replikáció és a feladatátvétel engedélyezésével.Provides high availability at the data tier, by enabling replication and failover. A feladatátvételhez a Windows Server feladatátvételi fürt (WSFC) technológiáját használja.It uses Windows Server Failover Cluster (WSFC) technology for failover.

  • (AD DS) Active Directory Domain Services-kiszolgálókActive Directory Domain Services (AD DS) Servers. A feladatátvevő fürt és a hozzá tartozó fürtözött szerepkörök számítógép-objektumai a Active Directory tartományi szolgáltatásokban (AD DS) jönnek létre.The computer objects for the failover cluster and its associated clustered roles are created in Active Directory Domain Services (AD DS). Az azonos virtuális hálózatban lévő virtuális gépeken AD DS-kiszolgálók beállítása előnyben részesített módszer a más virtuális gépekhez való csatlakozásra AD DS.Set up AD DS servers in VMs in the same virtual network are preferred method to join other VMs to AD DS. A virtuális gépeket a meglévő vállalati AD DShoz is csatlakoztathatja, ha VPN-kapcsolattal csatlakozik a vállalati hálózathoz.You can also join the VMs to existing Enterprise AD DS by connecting virtual network to Enterprise network with VPN connection. Mindkét módszer esetében módosítania kell a virtuális hálózat DNS-jét a AD DS DNS-kiszolgálóra (virtuális hálózaton vagy meglévő vállalati hálózatban) a AD DS tartomány teljes tartománynevének feloldásához.With both approaches, you need to change the virtual network DNS to your AD DS DNS server (in virtual network or existing Enterprise network) to resolve the AD DS domain FQDN.

  • Felhőbeli tanúsító.Cloud Witness. A feladatátvevő fürtök több mint felet igényelnek a csomópontok futtatásához, amely kvórumnak ismert.A failover cluster requires more than half of its nodes to be running, which is known as having quorum. Ha a fürt csak két csomóponttal rendelkezik, a hálózati partíciók az egyes csomópontok esetében úgy gondolják, hogy ez a fő csomópont.If the cluster has just two nodes, a network partition could cause each node to think it's the master node. Ebben az esetben szükség van egy tanúra a kapcsolatok megszakításához és a kvórum létrehozásához.In that case, you need a witness to break ties and establish quorum. A tanúsító egy olyan erőforrás, például egy megosztott lemez, amely döntetlen-MEGSZAKÍTÓKÉNT működhet kvórum létrehozásához.A witness is a resource such as a shared disk that can act as a tie breaker to establish quorum. A Felhőbeli tanúsító olyan tanúsító típus, amely az Azure Blob Storage-t használja.Cloud Witness is a type of witness that uses Azure Blob Storage. A kvórum fogalmával kapcsolatos további tudnivalókért tekintse meg a fürt és a készlet Kvórumának ismertetésecímű témakört.To learn more about the concept of quorum, see Understanding cluster and pool quorum. A Felhőbeli tanúsító szolgáltatással kapcsolatos további információkért lásd: Felhőbeli tanúsító üzembe helyezése feladatátvevő fürtön.For more information about Cloud Witness, see Deploy a Cloud Witness for a Failover Cluster. Azure Stack központban a Felhőbeli tanúsító végpont különbözik a globális Azure-tól.In Azure Stack Hub, the Cloud Witness endpoint is different from global Azure.

A következőhöz hasonló lehet:It may look like:

  • Globális Azure esetén:For global Azure:
    https://mywitness.blob.core.windows.net/

  • Azure Stack hub esetében:For Azure Stack Hub:
    https://mywitness.blob.<region>.<FQDN>

  • Jumpbox.Jumpbox. Más néven bástyagazdagép.Also called a bastion host. A hálózaton található biztonságos virtuális gép, amelyet a rendszergazdák a többi virtuális géphez való kapcsolódásra használnak.A secure VM on the network that administrators use to connect to the other VMs. A jumpbox olyan NSG-vel rendelkezik, amely csak a biztonságos elemek listáján szereplő nyilvános IP-címekről érkező távoli forgalmat engedélyezi.The jumpbox has an NSG that allows remote traffic only from public IP addresses on a safe list. Az NSG-nek engedélyeznie kell a távoli asztali (RDP) forgalmat.The NSG should permit remote desktop (RDP) traffic.

JavaslatokRecommendations

Az Ön követelményei eltérhetnek az itt leírt architektúrától.Your requirements might differ from the architecture described here. Ezeket a javaslatokat tekintse kiindulópontnak.Use these recommendations as a starting point.

Virtual machines (Virtuális gépek)Virtual machines

A virtuális gépek konfigurálásával kapcsolatos javaslatokért lásd: Windows rendszerű virtuális gép futtatása Azure stack hub-on.For recommendations on configuring the VMs, see Run a Windows VM on Azure Stack Hub.

Virtuális hálózatVirtual network

A virtuális hálózat létrehozásakor határozza meg, hogy hány IP-cím szükséges az egyes alhálózatokban lévő erőforrásokhoz.When you create the virtual network, determine how many IP addresses your resources in each subnet require. A szükséges IP-címekhez a CIDR -jelölés használatával egy alhálózati maszkot és egy hálózati címtartományt kell megadni.Specify a subnet mask and a network address range large enough for the required IP addresses, using CIDR notation. Használjon a szabványos magánhálózati IP-címblokkokba eső címterületet. Ezek az IP-címblokkok a következők: 10.0.0.0/8, 172.16.0.0/12 és 192.168.0.0/16.Use an address space that falls within the standard private IP address blocks, which are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

Olyan címtartományt válasszon, amely nincs átfedésben a helyszíni hálózattal, ha később be kell állítania egy átjárót a virtuális hálózat és a helyszíni hálózat között.Choose an address range that does not overlap with your on-premises network, in case you need to set up a gateway between the virtual network and your on-premises network later. A virtuális hálózat létrehozása után a címtartomány nem módosítható.Once you create the virtual network, you can't change the address range.

Az alhálózatokat a funkciók és a biztonsági követelmények szem előtt tartásával tervezze meg.Design subnets with functionality and security requirements in mind. Minden ugyanazon szinthez vagy szerepkörhöz tartozó virtuális gépnek egyazon alhálózaton kell lennie. Ez az alhálózat biztonsági korlátot is képezhet.All VMs within the same tier or role should go into the same subnet, which can be a security boundary. A virtuális hálózatok és alhálózatok tervezésével kapcsolatos további információkért lásd: Azure Virtual Networks tervezése és kialakítása.For more information about designing virtual networks and subnets, see Plan and design Azure Virtual Networks.

TerheléselosztókLoad balancers

Ne tegye elérhetővé a virtuális gépeket közvetlenül az internethez, hanem adjon hozzá minden virtuális gépet egy magánhálózati IP-címhez.Don't expose the VMs directly to the Internet, but instead give each VM a private IP address. Az ügyfelek a 7. rétegbeli Load Balancerhoz társított nyilvános IP-cím használatával csatlakoznak.Clients connect using the public IP address associated with the Layer 7 Load Balancer.

Adja meg a terheléselosztó a virtuális gépek felé irányuló közvetlen hálózati forgalomra vonatkozó szabályait.Define load balancer rules to direct network traffic to the VMs. Ha például engedélyezni szeretné a HTTP-forgalmat, a 80-as portot az előtér-konfigurációból a 80-es portra a háttér-címkészlet esetében.For example, to enable HTTP traffic, map port 80 from the front-end configuration to port 80 on the back-end address pool. Amikor egy ügyfél HTTP-kérelmet küld a 80-as port felé, a terheléselosztó kiválaszt egy háttérbeli IP-címet egy kivonatoló algoritmus használatával, amely tartalmazza a forrás IP-címét.When a client sends an HTTP request to port 80, the load balancer selects a back-end IP address by using a hashing algorithm that includes the source IP address. Az ügyfelek kérései a háttérbeli címkészlet összes virtuális gépe között oszlanak meg.Client requests are distributed across all the VMs in the back-end address pool.

Hálózati biztonsági csoportokNetwork security groups

A szintek közötti forgalmat NSG-szabályokkal korlátozhatja.Use NSG rules to restrict traffic between tiers. A fentiekben bemutatott háromrétegű architektúrában a webes réteg nem kommunikál közvetlenül az adatbázis szintjével.In the three-tier architecture shown above, the web tier does not communicate directly with the database tier. A szabály betartatásához az adatbázis-szinten le kell tiltani a webes szintű alhálózatról érkező bejövő forgalmat.To enforce this rule, the database tier should block incoming traffic from the web tier subnet.

  1. A virtuális hálózatról érkező összes bejövő forgalom megtagadása.Deny all inbound traffic from the virtual network. (Használja a szabály VIRTUAL_NETWORK címkéjét.)(Use the VIRTUAL_NETWORK tag in the rule.)

  2. Az üzleti szintű alhálózatról érkező bejövő forgalom engedélyezése.Allow inbound traffic from the business tier subnet.

  3. Engedélyezze a bejövő forgalmat az adatbázis-rétegek alhálózatán.Allow inbound traffic from the database tier subnet itself. Ez a szabály lehetővé teszi az adatbázis-alapú virtuális gépek közötti kommunikációt, amely az adatbázis-replikációhoz és a feladatátvételhez szükséges.This rule allows communication between the database VMs, which is needed for database replication and failover.

  4. Engedélyezze az RDP-forgalmat (3389-es port) a Jumpbox alhálózaton.Allow RDP traffic (port 3389) from the jumpbox subnet. Ez lehetővé teszi, hogy a rendszergazdák csatlakozni tudjanak az adatbázisszinthez a jumpboxból.This rule lets administrators connect to the database tier from the jumpbox.

Hozzon létre a 2 – 4. szabályt magasabb prioritással, mint az első szabály, ezért bírálják felül.Create rules 2 – 4 with higher priority than the first rule, so they override it.

SQL Server Always On rendelkezésre állási csoportokSQL Server Always On Availability Groups

Magas rendelkezésre állású SQL Server esetén az Always On rendelkezésre állási csoportok használatát javasoljuk.We recommend Always On Availability Groups for SQL Server high availability. A Windows Server 2016-nál régebbi kiadásokban az Always On rendelkezésre állási csoportok tartományvezérlőt igényelnek, és a rendelkezésre állási csoport összes csomópontjának azonos AD-tartományban kell lennie.Prior to Windows Server 2016, Always On Availability Groups require a domain controller, and all nodes in the availability group must be in the same AD domain.

A virtuálisgép-réteg magas rendelkezésre állása esetén minden SQL virtuális gépnek rendelkezésre állási csoportnak kell lennie.For VM layer high availability, all SQL VMs should be in an Availability Set.

A többi szint egy rendelkezésre állási csoport figyelőjén keresztül csatlakozik az adatbázishoz.Other tiers connect to the database through an availability group listener. A figyelő lehetővé teszi, hogy az SQL-ügyfél anélkül csatlakozzon, hogy ismerné az SQL-kiszolgáló fizikai példányának nevét.The listener enables a SQL client to connect without knowing the name of the physical instance of SQL Server. Az adatbázishoz hozzáférő virtuális gépeket csatlakozni kell a tartományhoz.VMs that access the database must be joined to the domain. Az ügyfél (ebben az esetben egy másik szint) DNS használatával oldja fel a figyelő virtuális hálózati nevét IP-címekké.The client (in this case, another tier) uses DNS to resolve the listener's virtual network name into IP addresses.

A SQL Server Always On rendelkezésre állási csoportot az alábbiak szerint konfigurálja:Configure the SQL Server Always On Availability Group as follows:

  1. Hozzon létre egy Windows Server feladatátvételi fürtszolgáltatási (WSFC-) fürtöt, egy SQL Server Always On rendelkezésre állási csoportot és egy elsődleges replikát.Create a Windows Server Failover Clustering (WSFC) cluster, a SQL Server Always On Availability Group, and a primary replica. További információ: Ismerkedés az Always On rendelkezésre állási csoportokkal.For more information, see Getting Started with Always On Availability Groups.

  2. Hozzon létre egy belső terheléselosztót statikus magánhálózati IP-címmel.Create an internal load balancer with a static private IP address.

  3. Hozzon létre egy figyelőt a rendelkezésre állási csoporthoz, és rendelje hozzá a figyelő DNS-nevét a belső terheléselosztó IP-címéhez.Create an availability group listener, and map the listener's DNS name to the IP address of an internal load balancer.

  4. Hozzon létre egy terheléselosztó szabályt az SQL Server figyelőportjához (alapértelmezés szerint az 1433-as TCP-port).Create a load balancer rule for the SQL Server listening port (TCP port 1433 by default). A terheléselosztó szabálynak engedélyeznie kell a nem fix IP-címek használatát, más néven a közvetlen kiszolgálói választ.The load balancer rule must enable floating IP, also called Direct Server Return. Ezáltal a virtuális gép közvetlenül válaszol az ügyfélnek, és közvetlen kapcsolatot hozható létre az elsődleges replikával.This causes the VM to reply directly to the client, which enables a direct connection to the primary replica.

Megjegyzés

Ha a nem fix IP engedélyezve van, az előtérbeli portszámnak egyeznie kell a terheléselosztó szabály háttérbeli portszámával.When floating IP is enabled, the front-end port number must be the same as the back-end port number in the load balancer rule.

Ha egy SQL-ügyfél csatlakozni próbál, a terheléselosztó továbbítja az elsődleges replikának a kapcsolódási kérelmet.When a SQL client tries to connect, the load balancer routes the connection request to the primary replica. Ha van feladatátvétel egy másik replikára, a terheléselosztó automatikusan új elsődleges replikára irányítja az új kéréseket.If there is a failover to another replica, the load balancer automatically routes new requests to a new primary replica. További információ: ILB-figyelő konfigurálása SQL Server Always On rendelkezésre állási csoportokhoz.For more information, see Configure an ILB listener for SQL Server Always On Availability Groups.

A feladatátvétel során a meglévő ügyfélkapcsolatok lezárulnak.During a failover, existing client connections are closed. A feladatátvétel befejezése után a rendszer az új elsődleges replikára irányítja az új kapcsolatokat.After the failover completes, new connections will be routed to the new primary replica.

Ha az alkalmazás több olvasási műveletet tesz lehetővé, mint az írás, a csak olvasható lekérdezések egy részét kiszervezheti egy másodlagos replikára.If your application makes more reads than writes, you can offload some of the read-only queries to a secondary replica. Lásd: Csak olvasási másodlagos replikához való csatlakozás figyelővel (csak olvasási útválasztás).See Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing).

Kényszerítse a rendelkezésre állási csoport manuális feladatátvételét az üzemelő példány teszteléséhez.Test your deployment by forcing a manual failover of the availability group.

Az SQL-teljesítmény optimalizálása érdekében a Azure stack hub teljesítményének optimalizálásához az SQL Server ajánlott eljárásaitis megtekintheti.For SQL performance optimization, you can also refer the article SQL server best practices to optimize performance in Azure Stack Hub.

JumpboxJumpbox

Ne engedélyezze az RDP-hozzáférést a nyilvános internetről az alkalmazás számítási feladatait futtató virtuális gépekre.Don't allow RDP access from the public Internet to the VMs that run the application workload. Ehelyett ezeknek a virtuális gépeknek az összes RDP-elérését át kell lépnie a Jumpbox.Instead, all RDP access to these VMs should go through the jumpbox. A rendszergazda először bejelentkezik a jumpboxba, majd azon keresztül bejelentkezik a többi virtuális gépbe.An administrator logs into the jumpbox, and then logs into the other VM from the jumpbox. A jumpbox engedélyezi az internetről érkező RDP-forgalmat, de csak az ismert, biztonságos IP-címekről.The jumpbox allows RDP traffic from the Internet, but only from known, safe IP addresses.

A Jumpbox minimális teljesítménnyel kapcsolatos követelményekkel rendelkezik, ezért válassza ki a kis méretű virtuális gép méretét.The jumpbox has minimal performance requirements, so select a small VM size. Hozzon létre egy nyilvános IP-címet a jumpbox számára.Create a public IP address for the jumpbox. Helyezze a Jumpbox ugyanabban a virtuális hálózatban, mint a többi virtuális gépet, de egy különálló felügyeleti alhálózaton.Place the jumpbox in the same virtual network as the other VMs, but in a separate management subnet.

A Jumpbox biztonságossá tételéhez adjon hozzá egy olyan NSG-szabályt, amely csak a biztonságos nyilvános IP-címekről engedélyezi az RDP-kapcsolatokat.To secure the jumpbox, add an NSG rule that allows RDP connections only from a safe set of public IP addresses. Állítsa be az NSG-t a többi alhálózathoz is úgy, hogy engedélyezzék a felügyeleti alhálózatból érkező RDP-forgalmat.Configure the NSGs for the other subnets to allow RDP traffic from the management subnet.

Méretezési szempontokScalability considerations

Méretezési csoportokScale sets

A webes és az üzleti szintek esetében érdemes lehet virtuálisgép-méretezési csoportokat használni a különálló virtuális gépek üzembe helyezése helyett.For the web and business tiers, consider using virtual machine scale sets instead of deploying separate VMs. A méretezési csoport megkönnyíti az azonos virtuális gépek készletének üzembe helyezését és kezelését.A scale set makes it easy to deploy and manage a set of identical VMs. Ha gyorsan ki szeretné bővíteni a virtuális gépeket, vegye figyelembe a méretezési csoportokat.Consider scale sets if you need to quickly scale out VMs.

A méretezési csoportokban üzembe helyezett virtuális gépek konfigurálásának két alapvető módja van:There are two basic ways to configure VMs deployed in a scale set:

  • A bővítmények használatával konfigurálhatja a virtuális gépet a telepítés után.Use extensions to configure the VM after it's deployed. Ezzel a módszerrel az új virtuálisgép-példányok indítása több időt vehet igénybe, mint a bővítmények nélküli virtuális gépeké.With this approach, new VM instances may take longer to start up than a VM with no extensions.

  • Üzembe helyezhet egy felügyelt lemezt egy egyéni rendszerképpel.Deploy a managed disk with a custom disk image. Ez a módszer gyorsabban kivitelezhető.This option may be quicker to deploy. Azonban a rendszerképek naprakészen tartása szükséges.However, it requires you to keep the image up-to-date.

További információ: tervezési szempontok a méretezési csoportokhoz.For more information, see Design considerations for scale sets. Ez a kialakítási szempont általában a Azure Stack hub esetében igaz, de vannak bizonyos figyelmeztetések:This design consideration is mostly true for Azure Stack Hub, however there are some caveats:

  • A Azure Stack hub virtuálisgép-méretezési csoportjai nem támogatják a túlzott kiépítést vagy a működés közbeni frissítést.Virtual machine scale sets on Azure Stack Hub do not support overprovisioning or rolling upgrades.

  • Azure Stack hub-beli virtuálisgép-méretezési csoportok nem méretezhetők át.You cannot autoscale virtual machine scale sets on Azure Stack Hub.

  • Javasoljuk, hogy felügyelt lemezeket használjon Azure Stack hub-on a virtuálisgép-méretezési csoport nem felügyelt lemezei helyettWe strongly recommend using Managed disks on Azure Stack Hub instead of unmanaged disks for virtual machine scale set

  • Jelenleg egy 700 virtuális gép korlátja van Azure Stack hub-ra, amely az összes Azure Stack hub-infrastruktúra, az egyes virtuális gépek és a méretezési csoport példányainak fiókja.Currently, there is a 700 VM limit on Azure Stack Hub, which accounts for all Azure Stack Hub infrastructure VMs, individual VMs, and scale set instances.

Előfizetés korlátaiSubscription limits

Minden Azure Stack hub-bérlői előfizetés alapértelmezett korláttal rendelkezik, beleértve az Azure Stack hub-operátor által konfigurált régiónként engedélyezett maximális számú virtuális gépet.Each Azure Stack Hub tenant subscription has default limits in place, including a maximum number of VMs per region configured by the Azure Stack Hub operator. További információ: Azure stack hub-szolgáltatások, csomagok, ajánlatok, előfizetések áttekintése.For more information, see Azure Stack Hub services, plans, offers, subscriptions overview. Tekintse meg az Azure stack hub kvótáinak típusaitis.Also refer to Quota types in Azure Stack Hub.

Biztonsági szempontokSecurity considerations

A virtuális hálózatok forgalomelkülönítési határok az Azure-ban.Virtual networks are a traffic isolation boundary in Azure. Alapértelmezés szerint az egyik virtuális hálózatban lévő virtuális gépek nem tudnak közvetlenül kommunikálni egy másik virtuális hálózatban lévő virtuális gépekkel.By default, VMs in one virtual network can't communicate directly with VMs in a different virtual network.

NSG.NSGs. Hálózati biztonsági csoportok (NSG) használata az internetre irányuló és onnan érkező forgalom korlátozására.Use network security groups (NSGs) to restrict traffic to and from the internet. További információ: A Microsoft felhőszolgáltatásai és hálózati biztonság.For more information, see Microsoft cloud services and network security.

DMZ.DMZ. Érdemes lehet hozzáadnia egy hálózati virtuális berendezést (network virtual appliance, NVA), hogy DMZ-t lehessen létrehozni az internet és az Azure-beli virtuális hálózat között.Consider adding a network virtual appliance (NVA) to create a DMZ between the Internet and the Azure virtual network. Az NVA egy általános kifejezés egy olyan virtuális berendezésre, amely hálózatokhoz kapcsolódó feladatokat lát el, például gondoskodik a tűzfalról, a csomagvizsgálatról, a naplózásról és az egyéni útválasztásról.NVA is a generic term for a virtual appliance that can perform network-related tasks, such as firewall, packet inspection, auditing, and custom routing.

Titkosítás.Encryption. Titkosítsa a bizalmas adatokat, és a Azure stack Hub Key Vault használatával kezelheti az adatbázis-titkosítási kulcsokat.Encrypt sensitive data at rest and use Key Vault in Azure Stack Hub to manage the database encryption keys. További információkért lásd: Configure Azure Key Vault Integration for SQL Server on Azure VMs Az Azure Key Vault-integráció konfigurálása az SQL Serverhez Azure virtuális gépeken.For more information, see Configure Azure Key Vault Integration for SQL Server on Azure VMs. Javasoljuk továbbá, hogy az alkalmazás-titkokat, például az adatbázis-kapcsolódási karakterláncokat a Key Vault tárolja.It's also recommended to store application secrets, such as database connection strings, in Key Vault.

Következő lépésekNext steps