Delen via

Wat is SDN Multisite?

  • Artikel

Van toepassing op: Azure Local, versie 23H2

Van toepassing op: Windows Server 2025

Dit artikel bevat een overzicht van SDN Multisite, met inbegrip van de voordelen en huidige beperkingen. U kunt deze gebruiken als richtlijn voor het ontwerpen van uw netwerktopologie en noodherstelplan.

Met SDN Multisite kunt u de mogelijkheden van traditionele SDN uitbreiden die op verschillende fysieke locaties zijn geïmplementeerd. SDN Multisite maakt systeemeigen Laag 2- en Laag 3-connectiviteit mogelijk op verschillende fysieke locaties voor gevirtualiseerde workloads. In dit artikel verwijzen alle verwijzingen naar sites naar fysieke locaties.

Zie SDN Multisite beheren voor Azure Local voor meer informatie over het beheren van SDN Multisite.

Zie SDN Multisite beheren voor Azure Local voor meer informatie over het beheren van SDN Multisite.

Vergoedingen

Dit zijn de voordelen van het gebruik van SDN Multisite:

  • Geïntegreerd systeem voor beleidsbeheer. Met gedeelde virtuele netwerken en beleidsconfiguraties kunt u uw netwerken met meerdere locaties vanaf elke site beheren en configureren.
  • Naadloze workloadmigratie. Werkbelastingen naadloos migreren op fysieke sites zonder dat u IP-adressen opnieuw hoeft te configureren of bestaande netwerkbeveiligingsgroepen (NSG's).
  • Automatische bereikbaarheid voor nieuwe VM's. Krijg automatische bereikbaarheid voor nieuw gemaakte virtuele machines (VM's) in virtuele netwerken, samen met automatische beheerbaarheid voor een van de bijbehorende NSG's op uw fysieke locaties.

Beperkingen

De functie SDN Multisite heeft momenteel enkele beperkingen:

  • Alleen ondersteund tussen twee sites.
  • Sites moeten zijn verbonden via een particulier netwerk, omdat versleutelingsondersteuning voor sites die via internet zijn verbonden, niet is opgegeven.
  • Interne taakverdeling wordt niet ondersteund op meerdere sites.

Peering voor meerdere sites

Voor meerdere sites is peering vereist tussen sites, die worden geïnitieerd als peering van virtuele netwerken. Er wordt automatisch een verbinding gestart op beide sites via het Windows-beheercentrum. Nadat een verbinding tot stand is gebracht, wordt peering geslaagd. Zie Peering tot stand brengen voor instructies over het tot stand brengen van peering.

Voor meerdere sites is peering vereist tussen sites, die worden geïnitieerd als peering van virtuele netwerken. Er wordt automatisch een verbinding gestart op beide sites via het Windows-beheercentrum. Zodra een verbinding tot stand is gebracht, wordt peering geslaagd. Zie Peering tot stand brengen voor instructies over het tot stand brengen van peering.

In de volgende secties wordt beschreven wat de rollen van elke site binnen een omgeving met meerdere locaties zijn en hoe resources worden verwerkt en gesynchroniseerd tussen sites.

Primaire en secundaire siterollen

In een SDN-omgeving met meerdere locaties wordt één site aangewezen als de primaire en de andere als secundair. De primaire site verwerkt resourcesynchronisatie. Tijdens peering voor meerdere sites wordt de primaire site automatisch geselecteerd, die u later kunt wijzigen met behulp van het Windows-beheercentrum.

Resourceafhandeling

  • Als de primaire site onbereikbaar is, kunnen globale resources en resources waarvoor globale validatie of globale CA-toewijzingen (Customer Address) zijn vereist, niet worden bijgewerkt via secundaire site. Andere lokale resources kunnen echter worden bijgewerkt via een secundaire site.

    Voorbeelden van resources die globale validatie nodig hebben, zijn:

    • MAC-pools.
    • Logisch netwerk/IP-adresgroep.

    Voorbeelden van globale CA-toewijzingen zijn:

    • Interne taakverdeling voor virtueel subnet. Dit wordt momenteel niet ondersteund via meerdere sites.
    • Gatewayverbindingen voor virtueel subnet.

  • Als de secundaire site onbereikbaar is, kunnen resources worden bijgewerkt via de primaire site. De secundaire site kan echter verlopen resources hebben totdat de verbinding is hersteld. Zodra de verbinding is hersteld, wordt de synchronisatie hervat.

  • Als de primaire site uitvalt, kunt u uw secundaire site aanwijzen als de nieuwe primaire site om updates uit te voeren voor uw netwerkbeveiligingsgroepen en virtuele netwerken. Alle in behandeling zijnde gegevenssynchronisatie van de oude primaire site gaan echter verloren. Als u dit probleem wilt oplossen, past u dezelfde wijzigingen toe op de nieuwe primaire site zodra de oude primaire site weer online is. Het kan echter ook leiden tot wereldwijde CA-toewijzingsconflicten.

Resourcesynchronisatie

Wanneer u SDN Multisite inschakelt, worden niet alle resources van elke site gesynchroniseerd op alle sites. Hier volgen de lijsten met resources die worden gesynchroniseerd en die niet-gesynchroniseerd blijven.

  • Niet-gesynchroniseerde resources

    Deze resources worden niet gesynchroniseerd nadat peering tot stand is gebracht:

    • Taakverdelingsbeleid.
    • Virtuele IP-adressen (VIP's).
    • Gatewaybeleid.
    • Logische netwerken. Hoewel logische netwerken niet worden gesynchroniseerd tussen sites, worden IP-pools gecontroleerd op overlapping en is overlap niet toegestaan.

    Deze beleidsregels worden gemaakt op de lokale site en als u hetzelfde beleid op de andere site wilt, moet u ze daar handmatig maken. Als uw back-end-VM's voor taakverdelingsbeleid zich op één site bevinden, werkt de connectiviteit via SLB prima zonder extra configuratie. Maar als u verwacht dat de back-end-VM's van de ene site naar de andere worden verplaatst, werkt de connectiviteit alleen als er back-end-VM's achter een VIP op de lokale site staan. Als alle back-end-VM's naar een andere site worden verplaatst, mislukt de connectiviteit via dat VIP.

Oost-west verkeersstroom en delen van subnetten

Met meerdere sites kunnen VM's op verschillende sites waarop SDN is geïmplementeerd, communiceren via hetzelfde subnet zonder dat u SDN-gatewayverbindingen hoeft in te stellen. Dit vereenvoudigt de netwerktopologie en vermindert de behoefte aan meer VM's en subnetten. Het gegevenspad tussen VM's op verschillende sites is afhankelijk van de onderliggende fysieke infrastructuur.

In de volgende scenario's wordt vergeleken hoe vm-communicatie tot stand wordt gebracht tussen twee fysieke sites in een traditionele SDN-installatie versus in een SDN Multisite-installatie.

VM-naar-VM-communicatie zonder SDN-multisite

In een traditionele installatie met SDN die is geïmplementeerd op twee fysieke sites, moet u een L3- of GRE-gatewayverbinding tot stand brengen voor communicatie tussen sites. U moet ook meer subnetten voor uw toepassingen opgeven. Als elke site bijvoorbeeld front-endtoepassingen host, wijst u afzonderlijke subnetbereiken toe, zoals 10.1/16 en 10.6/16. Bovendien moet u bij het instellen van een gatewayverbinding ook meer VM's toewijzen voor uw gateway-VM's en deze daarna beheren.

Diagram voor het weergeven van vm-naar-VM-communicatie tussen twee fysieke sites in een traditionele SDN-installatie.

VM-naar-VM-communicatie met SDN Multisite

Met SDN Multisite op twee fysieke locaties kunt u systeemeigen Laag 2-connectiviteit hebben voor communicatie tussen sites. Hierdoor kunt u één subnetbereik hebben voor uw toepassingen die zich op beide locaties bevinden, waardoor u geen SDN-gatewayverbinding hoeft in te stellen. Zoals in het volgende diagram wordt geïllustreerd, kunnen front-endtoepassingen op beide locaties bijvoorbeeld hetzelfde subnet gebruiken, zoals 10.1/16, in plaats van twee afzonderlijke toepassingen te onderhouden. Met deze installatie is de gegevensstroom van de ene VM naar de andere alleen afhankelijk van uw onderliggende fysieke infrastructuur, waardoor u geen andere SDN-gateway-VM hoeft te doorlopen.

Diagram voor het weergeven van VM-naar-VM-communicatie met SDN Multisite.

Software Load Balancers en hun beperkingen

Op dit moment zijn Software Load Balancers lokale resources voor elk van uw fysieke sites. Dit betekent dat taakverdelingsbeleid en -configuraties niet worden gesynchroniseerd tussen sites via meerdere sites. Houd dit in gedachten wanneer u VM's migreert van de ene locatie naar de andere in een SDN Multisite-installatie.

Taakverdeling in SDN Multisite: Voorbeeldscenario

In de volgende secties wordt taakverdeling in meerdere locaties uitgelegd via een voorbeeldscenario, waarbij zowel zonder als met het migreren van workload-VM's wordt gedemonstreerd. Stel dat u twee lokale Azure-exemplaren hebt waarvoor SDN Multisite is ingeschakeld, elk met een eigen SDN-infrastructuur die is geïmplementeerd en geconfigureerd. In dit scenario wil een client VM1 bereiken met IP-adres 10.0.0.5 en VIP van 11.0.0.5.

Taakverdeling in SDN Multisite zonder workload-VM's te migreren

Als er in SDN meerdere locaties geen VM-migratie tussen locaties is, worden gegevenspakketten zoals gebruikelijk doorgestuurd, vergelijkbaar met de traditionele SDN-installatie. De volgende animatie illustreert het gegevenspad van de clientcomputer naar VM1 via SLB MUX1 in Cluster 2.

Animatie die taakverdeling weergeeft in een SDN-omgeving met meerdere locaties zonder workloads te migreren.

Taakverdeling in SDN Multisite met migratie van workload-VM's

Als u besluit om één VIRTUELE machine of alle VM's achter het VIP naar de andere site te migreren, kunnen er situaties optreden waarin de VM die u probeert te bereiken, onbereikbaar wordt via het VIP, afhankelijk van de locatie. Dit gebeurt omdat load balancer-resources lokaal zijn voor elk Lokaal Azure-exemplaar. Naarmate de workload-VM's worden verplaatst, zijn de configuraties op de MUXes niet globaal, waardoor de andere site zich niet bewust is van migraties. In de volgende animatie ziet u de migratie van vm's van Cluster 2 naar Cluster 1 en hoe het pad van het gegevenspakket na de migratie mislukt.

Animatie die taakverdeling weergeeft in een SDN-omgeving met meerdere locaties met het migreren van workloads.

Als u deze beperking wilt omzeilen, kunt u een externe load balancer gebruiken waarmee de beschikbaarheid van back-end-VM's op elke site wordt gecontroleerd en het verkeer dienovereenkomstig wordt gerouteerd. Zie Externe load balancer gebruiken in meerdere locaties met het migreren van workload-VM's.

Externe load balancer gebruiken in meerdere locaties met het migreren van workload-VM's

U kunt een externe load balancer inschakelen om te controleren of er back-end-VM's achter een load balancer op een van uw sites staan. Als er geen back-end-VM's achter een load balancer staan, wordt het VIP voor de MUX niet geadverteerd naar de externe load balancer en mislukt de statustest die wordt verzonden. Deze externe load balancer zorgt voor connectiviteit met workloads, zelfs als VM's van de ene site naar de andere gaan.

Diagram van het gebruik van een lokale balancer voor externe software als een oplossing voor het migreren van VM's tussen sites in een installatie met meerdere locaties.

Als het implementeren van een externe load balancer echter niet haalbaar is, gebruikt u de oplossing voor softwaretaakverdeling, zoals beschreven in Taakverdeling in SDN Multisite zonder workload-VM's te migreren zolang u geen workload-VM's hebt.

Gateways en hun beperkingen

SDN-multisite synchroniseert geen lokale resources, zoals gatewayverbindingen tussen sites. Elke site heeft zijn eigen gateway-VM's en gatewayverbindingen. Wanneer een workload-VM wordt gemaakt of gemigreerd naar een site, krijgt deze lokale gatewayconfiguratie, zoals gatewayroutes. Als u een gatewayverbinding voor een bepaald virtueel netwerk op de ene site maakt, verliezen VM's van die site de gatewayverbinding bij migratie naar de andere site. Voor vm's die gatewayconnectiviteit behouden bij migratie, moet u een afzonderlijke gatewayverbinding configureren voor hetzelfde virtuele netwerk op de andere site.

Volgende stappen

SDN-multisite beheren voor Azure Local

SDN-multisite beheren voor Azure Local