Többrégiós N szintű alkalmazás

Monitor
Traffic Manager
SQL Database
Virtual Machines

Ez a referenciaarchitektúra néhány bevált eljárást mutat be egy N szintű alkalmazás több Azure-régióban való futtatásához a magas rendelkezésre állás eléréséhez és egy robusztus vészhelyreállítási infrastruktúra kiépítéséhez.This reference architecture shows a set of proven practices for running an N-tier application in multiple Azure regions, in order to achieve availability and a robust disaster recovery infrastructure.

Nagy rendelkezésre állású hálózati architektúra az Azure N szintű alkalmazásokhoz

Töltse le az architektúra Visio-fájlját.Download a Visio file of this architecture.

ArchitektúraArchitecture

Ez az architektúra az N szintű alkalmazásban SQL Server.This architecture builds on the one shown in N-tier application with SQL Server.

  • Elsődleges és másodlagos régiók.Primary and secondary regions. Használjon két régiót a magas rendelkezésre állás eléréséhez.Use two regions to achieve higher availability. Az egyik ebben az esetben az elsődleges régió.One is the primary region. A másik a feladatátvétel során használt régió.The other region is for failover.

  • Azure Traffic Manager.Azure Traffic Manager. A Traffic Manager az egyik régió felé irányítja a beérkező kérelmeket.Traffic Manager routes incoming requests to one of the regions. A normál működés során a rendszer az elsődleges régió felé irányítja a kérelmeket.During normal operations, it routes requests to the primary region. Ha az adott régió nem érhető el, a Traffic Manager átadj a feladatokat a másodlagos régiónak.If that region becomes unavailable, Traffic Manager fails over to the secondary region. További információt a következő szakaszban talál: A Traffic Manager konfigurációja.For more information, see the section Traffic Manager configuration.

  • Erőforráscsoportok.Resource groups. Hozzon létre külön erőforráscsoportokat az elsődleges régióhoz, a másodlagos régióhoz, valamint a Traffic Managerhez.Create separate resource groups for the primary region, the secondary region, and for Traffic Manager. Ennek köszönhetően rugalmasan, egyetlen erőforráskészletként kezelheti az egyes régiókat,This gives you the flexibility to manage each region as a single collection of resources. például ismételten üzembe helyezhet egy régiót a másik eltávolítása nélkül.For example, you could redeploy one region, without taking down the other one. Kapcsolja össze az erőforráscsoportokat, hogy egy lekérdezés futtatásával listázhassa az alkalmazás összes erőforrását.Link the resource groups, so that you can run a query to list all the resources for the application.

  • Virtuális hálózatok.Virtual networks. Hozzon létre külön virtuális hálózatot az egyes régiókban.Create a separate virtual network for each region. Ügyeljen arra, hogy a címterek ne legyenek átfedésben.Make sure the address spaces do not overlap.

  • SQL Server always on rendelkezésre állási csoport.SQL Server Always On Availability Group. Az SQL Server használata esetén az SQL Server Always On rendelkezésre állási csoportok használata javasolt a magas rendelkezésre állás érdekében.If you are using SQL Server, we recommend SQL Always On Availability Groups for high availability. Hozzon létre egyetlen rendelkezésre állási csoportot, amely mindkét régióban tartalmazza az SQL Server-példányokat.Create a single availability group that includes the SQL Server instances in both regions.

    Megjegyzés

    Másik lehetőségként fontolja meg az Azure SQL Database használatát, amely relációs adatbázist biztosít felhőszolgáltatás formájában.Also consider Azure SQL Database, which provides a relational database as a cloud service. Az SQL Database használatával nem kell rendelkezésre állási csoportot konfigurálnia, vagy kezelnie a feladatátvételt.With SQL Database, you don't need to configure an availability group or manage failover.

  • Virtuális hálózat társítása.Virtual network peering. Egyenrangúként a két virtuális hálózat lehetővé teszi az adatok replikálását az elsődleges régióból a másodlagos régióba.Peer the two virtual networks to allow data replication from the primary region to the secondary region. További információ: Virtual Network peering.For more information, see Virtual network peering.

JavaslatokRecommendations

A többrégiós architektúrák magasabb rendelkezésre állást biztosíthatnak, mint az egyetlen régióban történő üzembe helyezés.A multi-region architecture can provide higher availability than deploying to a single region. Ha egy régió üzemkimaradása hatással van az elsődleges régióra, a Traffic Manager szolgáltatással feladatátvételt hajthat végre a másodlagos régióba.If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region. Ez az architektúra az alkalmazás egy adott alrendszerének meghibásodása esetén is segíthet.This architecture can also help if an individual subsystem of the application fails.

A régiók közötti magas rendelkezésre állás elérésének több általános megközelítése van:There are several general approaches to achieving high availability across regions:

  • Aktív/passzív készenléti kiszolgálóval.Active/passive with hot standby. A forgalom az egyik régióra irányul, míg a másik készenléti kiszolgálón várakozik.Traffic goes to one region, while the other waits on hot standby. Készenléti kiszolgáló esetében a másodlagos régió virtuális gépei folyamatosan le vannak foglalva és futnak.Hot standby means the VMs in the secondary region are allocated and running at all times.
  • Aktív/passzív hidegtartalékkal.Active/passive with cold standby. A forgalom az egyik régióra irányul, míg a másik hidegtartalékként áll készenlétben.Traffic goes to one region, while the other waits on cold standby. Hidegtartalék esetében a másodlagos régió virtuális gépei nincsenek lefoglalva, amíg nem szükségessé nem válnak feladatátvétel céljából.Cold standby means the VMs in the secondary region are not allocated until needed for failover. Ezen megközelítés futtatása kevesebb költséggel jár, de a meghibásodáskor általában hosszabb időt vesz igénybe az üzembe állás.This approach costs less to run, but will generally take longer to come online during a failure.
  • Aktív/aktív.Active/active. Mindkét régió aktív, és a kérelmek terheléselosztással oszlanak meg közöttük.Both regions are active, and requests are load balanced between them. Ha egy régió elérhetetlenné válik, kikerül a rotációból.If one region becomes unavailable, it is taken out of rotation.

Ez a referenciaarchitektúra a készenléti kiszolgálóval konfigurált aktív/passzív üzemmódra összpontosít, a Traffic Managert használva a feladatátvételhez.This reference architecture focuses on active/passive with hot standby, using Traffic Manager for failover. Vegye figyelembe, hogy ha kis számú virtuális gépet helyez üzembe készenléti kiszolgálóként, igény szerint később is elvégezheti a horizontális felskálázásukat.Note that you could deploy a small number of VMs for hot standby and then scale out as needed.

Régiónkénti párosításRegional pairing

Minden egyes Azure-régió párban áll egy másikkal egy azonos földrajzi területen belül.Each Azure region is paired with another region within the same geography. Régiókat általában azonos regionális párokból érdemes választani (például: USA 2. keleti régiója és USA középső régiója).In general, choose regions from the same regional pair (for example, East US 2 and US Central). Ennek előnyei például a következők:Benefits of doing so include:

  • Széles körű leállás esetén a helyreállításkor minden párból legalább az egyik régió előnyt élvez.If there is a broad outage, recovery of at least one region out of every pair is prioritized.
  • A tervezett Azure-rendszerfrissítések egyszerre csak a régiópár egyik tagján jelennek meg, ami csökkenti az állásidőt.Planned Azure system updates are rolled out to paired regions sequentially, to minimize possible downtime.
  • A párok azonos földrajzi helyen belül találhatók, hogy megfeleljenek az adatok tárolási helyére vonatkozó előírásoknak.Pairs reside within the same geography, to meet data residency requirements.

Azonban győződjön meg arról, hogy mindkét régió támogatja az összes Azure-szolgáltatást, amely szükséges az alkalmazásához (lásd: Szolgáltatások régiónként).However, make sure that both regions support all of the Azure services needed for your application (see Services by region). További információk a regionális párokról: Üzletmenet-folytonosság és vészhelyreállítás (BCDR): Az Azure párosított régiói.For more information about regional pairs, see Business continuity and disaster recovery (BCDR): Azure Paired Regions.

A Traffic Manager konfigurációjaTraffic Manager configuration

A Traffic Manager konfigurálásakor vegye figyelembe a következő szempontokat:Consider the following points when configuring Traffic Manager:

  • Útválasztás.Routing. A Traffic Manager többféle útválasztási algoritmust támogat.Traffic Manager supports several routing algorithms. A cikkben leírt forgatókönyvhöz a prioritásos útválasztást (régebbi nevén feladatátvétel esetén használt útválasztás) használja.For the scenario described in this article, use priority routing (formerly called failover routing). Ezzel a beállítással a Traffic Manager az összes kérelmet az elsődleges régió felé irányítja, kivétel akkor, ha az nem elérhető.With this setting, Traffic Manager sends all requests to the primary region, unless the primary region becomes unreachable. Ebben az esetben automatikusan átadja a feladatokat a másodlagos régiónak.At that point, it automatically fails over to the secondary region. Lásd: A feladatátvétel esetén használt útválasztás konfigurálása.See Configure Failover routing method.
  • Állapot-mintavétel.Health probe. A Traffic Manager HTTP- (vagy HTTPS-) mintavételt használ az egyes régiók rendelkezésre állásának monitorozására.Traffic Manager uses an HTTP (or HTTPS) probe to monitor the availability of each region. A mintavétel 200-as HTTP-választ vár egy megadott URL-címhez.The probe checks for an HTTP 200 response for a specified URL path. Ajánlott eljárásként hozzon létre egy olyan végpontot, amely az alkalmazás általános állapotáról ad jelentést, és ezt a végpontot használja az állapotmintához.As a best practice, create an endpoint that reports the overall health of the application, and use this endpoint for the health probe. Ellenkező esetben előfordulhat, hogy a mintavétel megfelelően működő végpontot jelent, miközben az alkalmazás kritikus fontosságú részei valójában hibásak.Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing. További információ: állapot- végpont figyelési mintája.For more information, see Health Endpoint Monitoring pattern.

Amikor a Traffic Manager átadja a feladatokat, az alkalmazás egy ideig nem lesz elérhető a felhasználók számára.When Traffic Manager fails over there is a period of time when clients cannot reach the application. Ez az időtartam a következő tényezőktől függ:The duration is affected by the following factors:

  • Az állapotmintának észlelnie kell, ha az elsődleges régió elérhetetlenné válik.The health probe must detect that the primary region has become unreachable.
  • A DNS-kiszolgálóknak frissíteniük kell az IP-címhez tartozó gyorsítótárazott DNS-rekordokat. Ez a DNS élettartamától (TTL) függ.DNS servers must update the cached DNS records for the IP address, which depends on the DNS time-to-live (TTL). Az alapértelmezett TTL 300 másodperc (5 perc), de ezt az értéket a Traffic Manager-profil létrehozásakor konfigurálhatja.The default TTL is 300 seconds (5 minutes), but you can configure this value when you create the Traffic Manager profile.

Részletek: A Traffic Manager monitorozásának ismertetése.For details, see About Traffic Manager Monitoring.

Ha a Traffic Manager feladatátvételt hajt végre, automatikus feladat-visszavétel megvalósítása helyett a manuális feladat-visszavételt ajánlunk.If Traffic Manager fails over, we recommend performing a manual failback rather than implementing an automatic failback. Ellenkező esetben előfordulhat, hogy egyes esetekben az alkalmazás oda-vissza váltogat a régiók között.Otherwise, you can create a situation where the application flips back and forth between regions. A feladat-visszavétel előtt ellenőrizze, hogy az alkalmazás minden alrendszere működik-e.Verify that all application subsystems are healthy before failing back.

Vegye figyelembe, hogy a Traffic Manager alapértelmezés szerint automatikusan végrehajtja a feladat-visszavételt.Note that Traffic Manager automatically fails back by default. Ennek megelőzéséhez manuálisan csökkentse az elsődleges régió prioritását a feladatátvétel után.To prevent this, manually lower the priority of the primary region after a failover event. Tegyük fel például, hogy az elsődleges régió 1-es prioritású, a második pedig 2-es.For example, suppose the primary region is priority 1 and the secondary is priority 2. A feladatátvétel után az automatikus visszavétel megelőzéséhez állítsa az elsődleges régió prioritását 3-asra.After a failover, set the primary region to priority 3, to prevent automatic failback. A prioritást akkor állítsa 1-esre, ha már készen áll a visszaváltásra.When you are ready to switch back, update the priority to 1.

A következő Azure CLI-parancsot frissíti a prioritást:The following Azure CLI command updates the priority:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

Másik megoldásként ideiglenesen letilthatja a végpontot, amíg készen nem áll a feladat-visszavételre:Another approach is to temporarily disable the endpoint until you are ready to fail back:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

A feladatátvétel okától függően előfordulhat, hogy újra üzembe kell helyeznie az erőforrásokat a régión belül.Depending on the cause of a failover, you might need to redeploy the resources within a region. A feladat-visszavétel előtt tesztelje a működési készenlétet.Before failing back, perform an operational readiness test. A teszt többek között a következőket ellenőrzi:The test should verify things like:

  • A virtuális gépek megfelelően vannak-e konfigurálva.VMs are configured correctly. (Az összes szükséges szoftver telepítve van, az IIS fut stb.)(All required software is installed, IIS is running, and so on.)
  • Az alkalmazás alrendszerei működőképesek-e.Application subsystems are healthy.
  • Funkciótesztelés.Functional testing. (Pl. az adatbázisszint elérhető a webes szintről.)(For example, the database tier is reachable from the web tier.)

Az SQL Server Always On rendelkezésre állási csoportok konfigurálásaConfigure SQL Server Always On Availability Groups

A Windows Server 2016-nál régebbi kiadásokban az SQL Server 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 Active Directory (AD) tartományban kell lennie.Prior to Windows Server 2016, SQL Server Always On Availability Groups require a domain controller, and all nodes in the availability group must be in the same Active Directory (AD) domain.

Az rendelkezésre állási csoport konfigurálása:To configure the availability group:

  • Legalább két tartományvezérlőt helyezzen mindegyik régióba.At a minimum, place two domain controllers in each region.

  • Minden tartományvezérlőhöz rendeljen egy statikus IP-címet.Give each domain controller a static IP address.

  • A két virtuális hálózat társítása a közöttük való kommunikáció engedélyezéséhez.Peer the two virtual networks to enable communication between them.

  • Minden egyes virtuális hálózat esetében adja hozzá a tartományvezérlők IP-címeit (mindkét régióból) a DNS-kiszolgáló listájához.For each virtual network, add the IP addresses of the domain controllers (from both regions) to the DNS server list. Ezt az alábbi CLI-paranccsal teheti meg.You can use the following CLI command. További információ: DNS-kiszolgálók módosítása.For more information, see Change DNS servers.

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
    
  • Hozzon létre egy Windows Server feladatátvételi fürtszolgáltatást (WSFC) fürtöt, amely mindkét régióban tartalmazza SQL Server-példányokat.Create a Windows Server Failover Clustering (WSFC) cluster that includes the SQL Server instances in both regions.

  • Hozzon létre egy SQL Server Always On rendelkezésre állási csoportot, amely tartalmazza az elsődleges és a másodlagos régió SQL Server-példányait.Create a SQL Server Always On Availability Group that includes the SQL Server instances in both the primary and secondary regions. Ennek lépéseit az Always On rendelkezésre állási csoport kiterjesztése távoli Azure adatközpontra (PowerShell) című cikkben találja.See Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) for the steps.

    • Az elsődleges régiót helyezze az elsődleges régióba.Put the primary replica in the primary region.

    • Helyezzen egy vagy több másodlagos replikát az elsődleges régióba.Put one or more secondary replicas in the primary region. Konfigurálja azokat a szinkron véglegesítés használatára, automatikus feladatátvétellel.Configure these to use synchronous commit with automatic failover.

    • Helyezzen egy vagy több másodlagos replikát a másodlagos régióba.Put one or more secondary replicas in the secondary region. Ezeket a teljesítmény érdekében aszinkron véglegesítés használatára konfigurálja.Configure these to use asynchronous commit, for performance reasons. (Ellenkező esetben az összes T-SQL-tranzakciónak várnia kell, míg az adatok körbeérnek a hálózaton a másodlagos régióig.)(Otherwise, all T-SQL transactions have to wait on a round trip over the network to the secondary region.)

      Megjegyzés

      Az aszinkron véglegesítésű replikák nem támogatják az automatikus feladatátvételt.Asynchronous commit replicas do not support automatic failover.

Rendelkezésre állási szempontokAvailability considerations

Komplex N szintű alkalmazás esetén előfordulhat, hogy nem kell replikálnia a teljes alkalmazást a másodlagos régióba.With a complex N-tier app, you may not need to replicate the entire application in the secondary region. Ehelyett elég lehet replikálni egy kritikus fontosságú alrendszert, amely az üzletmenet folytonosságának fenntartásához szükséges.Instead, you might just replicate a critical subsystem that is needed to support business continuity.

A Traffic Manager a rendszer egyik lehetséges meghibásodási pontja.Traffic Manager is a possible failure point in the system. Ha a Traffic Manager szolgáltatás meghibásodik, az ügyfelek a leállás ideje alatt nem érhetik el az alkalmazást.If the Traffic Manager service fails, clients cannot access your application during the downtime. Tekintse át a Traffic Manager szolgáltatói szerződését, és döntse el, hogy a Traffic Manager egyedüli használata elegendő-e vállalata magas rendelkezésre állásra vonatkozó követelményeihez.Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. Ha nem, akkor a biztonság érdekében érdemes lehet hozzáadni egy másik forgalomkezelési szolgáltatást a feladat-visszavételhez.If not, consider adding another traffic management solution as a failback. Ha az Azure Traffic Manager szolgáltatás meghibásodik, módosítsa a CNAME rekordját a DNS-ben úgy, hogy a többi forgalomkezelő szolgáltatásra mutasson.If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service. (Ezt a lépést manuálisan kell elvégezni. Amíg a DNS-módosítások érvénybe nem lépnek, az alkalmazás nem lesz elérhető.)(This step must be performed manually, and your application will be unavailable until the DNS changes are propagated.)

Az SQL Server-fürt esetében két feladatátvételi forgatókönyvet kell figyelembe venni:For the SQL Server cluster, there are two failover scenarios to consider:

  • Az összes SQL Server-adatbázisreplika meghibásodik az elsődleges régióban.All of the SQL Server database replicas in the primary region fail. Ez például regionális kimaradás során fordulhat elő.For example, this could happen during a regional outage. Ebben az esetben manuálisan kell elvégeznie a rendelkezésre állási csoport feladatátvételét, annak ellenére, hogy a Traffic Manager az előtérben automatikusan elvégzi a feladatátvételt.In that case, you must manually fail over the availability group, even though Traffic Manager automatically fails over on the front end. Kövesse a Kényszerített manuális feladatátvétel elvégzése SQL Server rendelkezésre állási csoporton című cikk lépéseit. A cikk leírja, hogyan végezhető kényszerített feladatátvétel az SQL Server Management Studio, a Transact-SQL vagy a PowerShell használatával az SQL Server 2016-ban.Follow the steps in Perform a Forced Manual Failover of a SQL Server Availability Group, which describes how to perform a forced failover by using SQL Server Management Studio, Transact-SQL, or PowerShell in SQL Server 2016.

    Figyelmeztetés

    A kényszerített feladatátvétel esetében adatvesztés fordulhat elő.With forced failover, there is a risk of data loss. Amint az elsődleges régió újra elérhetővé válik, készítsen pillanatfelvételt az adatbázisról, és használja a tablediff parancsot a különbségek megkereséséhez.Once the primary region is back online, take a snapshot of the database and use tablediff to find the differences.

  • A Traffic Manager átadja a feladatokat a másodlagos régiónak, de az elsődleges SQL Server-adatbázisreplika továbbra is elérhető marad.Traffic Manager fails over to the secondary region, but the primary SQL Server database replica is still available. Például előfordulhat, hogy az előtérréteg meghibásodik, de ez nincs hatással az SQL Servert futtató virtuális gépekre.For example, the front-end tier might fail, without affecting the SQL Server VMs. Ebben az esetben a rendszer átirányítja az internetes forgalmat a másodlagos régióba, és ez a régió továbbra is csatlakozhat az elsődleges replikához.In that case, Internet traffic is routed to the secondary region, and that region can still connect to the primary replica. Ekkor azonban nagyobb lesz a késés, mivel az SQL Server-kapcsolatoknak több régión kell áthaladniuk.However, there will be increased latency, because the SQL Server connections are going across regions. Ebben a helyzetben manuálisan kell végrehajtania a feladatátvételt az alábbiak szerint:In this situation, you should perform a manual failover as follows:

    1. Ideiglenesen állítson át egy SQL Server-adatbázisreplikát a másodlagos régióban szinkron véglegesítésre.Temporarily switch a SQL Server database replica in the secondary region to synchronous commit. Ez biztosítja, hogy ne legyen adatvesztés a feladatátvétel során.This ensures there won't be data loss during the failover.
    2. Végezze el a feladatátvételt erre a replikára.Fail over to that replica.
    3. Miután megtörtént a feladat-visszavétel az elsődleges régióra, állítsa vissza az aszinkron véglegesítést.When you fail back to the primary region, restore the asynchronous commit setting.

Felügyeleti szempontokManageability considerations

Amikor frissíti az üzemelő példányt, egyszerre egy régiót frissítsen. Ezzel csökkenthető a nem megfelelő konfiguráció vagy az alkalmazásban felmerülő hiba okozta globális meghibásodás esélye.When you update your deployment, update one region at a time to reduce the chance of a global failure from an incorrect configuration or an error in the application.

Tesztelje a rendszer meghibásodásokkal szembeni rugalmasságát.Test the resiliency of the system to failures. Alább található néhány gyakori meghibásodási helyzet:Here are some common failure scenarios to test:

  • Állítson le virtuálisgép-példányokat.Shut down VM instances.
  • Terhelje az erőforrásokat, például a processzort és a memóriát.Pressure resources such as CPU and memory.
  • Bontsa/késleltesse a hálózati kapcsolatot.Disconnect/delay network.
  • Váltsa ki egyes folyamatok összeomlását.Crash processes.
  • Alkalmazzon lejárt tanúsítványokat.Expire certificates.
  • Szimuláljon hardverhibákat.Simulate hardware faults.
  • Állítsa le a DNS-szolgáltatást a tartományvezérlőkön.Shut down the DNS service on the domain controllers.

Mérje meg a helyreállítási időtartamokat, és győződjön meg róla, hogy azok megfelelnek az üzleti követelményeinek.Measure the recovery times and verify they meet your business requirements. Több hibaállapot kombinációját is tesztelje.Test combinations of failure modes, as well.

Költségekkel kapcsolatos szempontokCost considerations

A költségek becsléséhez használja az Azure díjszabási számológépét .Use the Azure Pricing Calculator to estimates costs. Néhány további szempont.Here are some other considerations.

Virtuálisgép-méretezési csoportokVirtual machine scale sets

A virtuálisgép-méretezési csoportok minden Windowsos VM-méretben elérhetők.Virtual machine scale sets are available on all Windows VM sizes. Csak az üzembe helyezett Azure-beli virtuális gépek, valamint az egyéb mögöttes infrastruktúra-erőforrások, például a tárolás és a hálózatkezelés után kell fizetni.You are only charged for the Azure VMs you deploy and any additional underlying infrastructure resources consumed such as storage and networking. A virtuálisgép-méretezési csoportok szolgáltatáshoz nem tartoznak növekményes díjak.There are no incremental charges for the Virtual machine scale sets service.

Az önálló virtuális gépek díjszabását lásd: Windows rendszerű virtuális gépek díjszabása.For single VMs pricing options, see Windows VMs pricing.

SQL ServerSQL server

Ha az Azure SQL DBaas választja, akkor a költségeket mentheti, mert nem kell konfigurálnia az Always On rendelkezésre állási csoportot és a tartományvezérlő gépeket.If you choose Azure SQL DBaas, you can save on cost because don't need to configure an Always On Availability Group and domain controller machines. Több üzembe helyezési lehetőség van az önálló adatbázisból a felügyelt példányokra vagy a rugalmas készletekre.There are several deployment options starting from single database up to managed instance, or elastic pools. További információ: az Azure SQL díjszabása.For more information see Azure SQL pricing.

Az SQL Server virtuális gépek díjszabási lehetőségeiről lásd: SQL virtuális gépek díjszabása.For SQL server VMs pricing options, see SQL VMs pricing.

TerheléselosztókLoad balancers

Csak a beállított terheléselosztási és kimenő szabályokért kell fizetnie.You are charged only for the number of configured load-balancing and outbound rules. A bejövő NAT-szabályok ingyenesek.Inbound NAT rules are free. A standard Load Balancer nem számítunk fel óradíjat, ha nincsenek beállítva szabályok.There is no hourly charge for the Standard Load Balancer when no rules are configured.

Díjszabás Traffic ManagerTraffic Manager pricing

Traffic Manager számlázás a kapott DNS-lekérdezések számától függ, és a több mint 1 000 000 000 havi lekérdezést fogadó szolgáltatások esetében kedvezményt biztosítunk.Traffic Manager billing is based on the number of DNS queries received, with a discount for services receiving more than 1 billion monthly queries. A figyelt végpontok díját is felszámítjuk.You are also charged for each monitored endpoint.

További információért lásd a Microsoft Azure Well-Architected Framework költségekkel kapcsolatos részét.For more information, see the cost section in Microsoft Azure Well-Architected Framework.

Díjszabás VNET-PeeringVNET-Peering pricing

A magas rendelkezésre állású üzembe helyezés több Azure-régiót használ a VNET.A high-availability deployment that leverages multiple Azure Regions will make use of VNET-Peering. Az azonos régión belüli VNET-Peering és a globális VNET eltérő díjakat számítunk fel.There are different charges for VNET-Peering within the same region and for Global VNET-Peering.

További információ: Virtual Network díjszabása.For more information, see Virtual Network Pricing.

A DevOps megfontolandó szempontjaiDevOps considerations

Az Azure-erőforrások és a hozzájuk tartozó függőségek kiépítés egyetlen Azure Resource Manager sablonnal .Use a single Azure Resource Manager template for provisioning the Azure resources and its dependencies. Ugyanazzal a sablonnal telepítheti az erőforrásokat az elsődleges és a másodlagos régiókban is.Use the same template to deploy the resources to both primary and secondary regions. Foglalja bele az összes erőforrást ugyanabban a virtuális hálózatban, hogy azok el legyenek különítve ugyanabban az alapszintű számítási feladatban, amely megkönnyíti a munkaterhelések konkrét erőforrásainak társítását egy DevOps-csapathoz, így a csapat egymástól függetlenül kezelheti az erőforrások összes aspektusát.Include all the resources in the same virtual network so they are isolated in the same basic workload, that makes it easier to associate the workload's specific resources to a DevOps team, so that the team can independently manage all aspects of those resources. Ez az elkülönítés lehetővé teszi, hogy a DevOps csapata és szolgáltatásai folyamatos integrációt és folyamatos teljesítést (CI/CD) végezzenek.This isolation enables DevOps Team and Services to perform continuous integration and continuous delivery (CI/CD).

Emellett különböző Azure Resource Manager sablonokat is használhat, és integrálhatja azokat az Azure DevOps Services szolgáltatással , hogy percek alatt kiépítse a különböző környezeteket, például az éles környezetben, vagy csak szükség esetén töltsön be tesztelési környezeteket, így megtakaríthatja a költségeket.Also, you can use different Azure Resource Manager templates and integrate them with Azure DevOps Services to provision different environments in minutes, for example to replicate production like scenarios or load testing environments only when needed, saving cost.

Érdemes az Azure Monitor használatával elemezni és optimalizálni az infrastruktúra teljesítményét, valamint monitorozni és diagnosztizálni a hálózati problémákat a virtuális gépekre való bejelentkezés nélkül.Consider using the Azure Monitor to Analyze and optimize the performance of your infrastructure, Monitor and diagnose networking issues without logging into your virtual machines. Application Insights a Azure Monitor egyik összetevője, amely gazdag mérőszámokat és naplókat biztosít a teljes Azure-környezet állapotának ellenőrzéséhez.Application Insights is actually one of the components of Azure Monitor, which gives you rich metrics and logs to verify the state of your complete Azure landscape. Azure Monitor segít az infrastruktúra állapotának követésében.Azure Monitor will help you to follow the state of your infrastructure.

Ügyeljen arra, hogy ne csak az alkalmazás kódját támogató számítási elemeket figyelje, hanem az adatplatformot is, különösen az adatbázisaiban, mivel az alkalmazások adatszintjének alacsony teljesítménye súlyos következményekkel járhat.Make sure not only to monitor your compute elements supporting your application code, but your data platform as well, in particular your databases, since a low performance of the data tier of an application could have serious consequences.

Az Azure-környezet teszteléséhez, ahol az alkalmazások futnak, a verziót az alkalmazás kódjával megegyező mechanizmusokkal kell vezérelni, és a DevOps-tesztelési paradigmák használatával is tesztelni és érvényesíteni kell.In order to test the Azure environment where the applications are running, it should be version-controlled and deployed through the same mechanisms as application code, then it can be tested and validated using DevOps testing paradigms too.

További információ: Microsoft Azure Well-Architected Frameworkműködési kiválósági szakasza.For more information, see the Operational Excellence section in Microsoft Azure Well-Architected Framework.

A következő architektúra ugyanazokat a technológiákat használja:The following architecture uses some of the same technologies: