Delen via

Azure Front Door gebruiken in een multitenant-oplossing

  • Artikel

Azure Front Door is een modern netwerk voor cloudinhoudlevering (CDN) dat snelle, betrouwbare toegang biedt tussen de statische en dynamische webinhoud van gebruikers en toepassingen over de hele wereld. In dit artikel worden enkele van de functies van Azure Front Door beschreven die handig zijn wanneer u in multitenant-systemen werkt. Het bevat ook koppelingen naar aanvullende richtlijnen en voorbeelden.

Wanneer u Azure Front Door gebruikt als onderdeel van een multitenant-oplossing, moet u enkele beslissingen nemen op basis van het ontwerp en de vereisten van uw oplossing. U moet rekening houden met de volgende factoren:

  • Hoeveel tenants hebt u en hoeveel verwacht u in de toekomst?
  • Deelt u uw toepassingslaag tussen meerdere tenants, implementeert u veel exemplaren van één tenanttoepassing of implementeert u afzonderlijke implementatiestempels die worden gedeeld door meerdere tenants?
  • Willen uw tenants hun eigen domeinnamen meenemen?
  • Gebruikt u jokertekendomeinen?
  • Moet u uw eigen TLS-certificaten gebruiken of beheert Microsoft uw TLS-certificaten?
  • Hebt u rekening gehouden met de quota en limieten die van toepassing zijn op Azure Front Door? Weet je welke limieten je nadert naarmate je groeit? Als u vermoedt dat u deze limieten nadert, kunt u overwegen om meerdere Azure Front Door-profielen te gebruiken. Of overweeg of u de manier waarop u Azure Front Door gebruikt, kunt wijzigen om de limieten te voorkomen. Houd er rekening mee dat de Premium-SKU hogere limieten heeft dan de Standard-SKU.
  • Hebben u of uw tenants vereisten voor het filteren van IP-adressen, geo-blokkeren of het aanpassen van WAF-regels?
  • Zijn alle toepassingsservers van uw tenants internetgericht?

Functies van Azure Front Door die ondersteuning bieden voor multitenancy

In deze sectie worden verschillende belangrijke functies van Azure Front Door beschreven die nuttig zijn voor multitenant-oplossingen. Hierin wordt beschreven hoe u met Azure Front Door aangepaste domeinen kunt configureren, waaronder informatie over jokertekendomeinen en TLS-certificaten. Ook wordt beschreven hoe u routeringsmogelijkheden van Azure Front Door kunt gebruiken ter ondersteuning van multitenancy.

Aangepaste domeinen

Azure Front Door biedt een standaardhostnaam voor elk eindpunt dat u maakt, contoso.z01.azurefd.netbijvoorbeeld. Voor de meeste oplossingen koppelt u in plaats daarvan uw eigen domeinnaam aan het Azure Front Door-eindpunt. Met aangepaste domeinnamen kunt u uw eigen huisstijl gebruiken en routering configureren op basis van de hostnaam die is opgegeven in de aanvraag van een client.

In een multitenant-oplossing kunt u tenantspecifieke domeinnamen of subdomeinen gebruiken en Azure Front Door configureren om het verkeer van de tenant te routeren naar de juiste oorsprongsgroep voor de workload van die tenant. U kunt bijvoorbeeld een aangepaste domeinnaam configureren, zoals tenant1.app.contoso.com. Met Azure Front Door kunt u meerdere aangepaste domeinen configureren op één Azure Front Door-profiel.

Raadpleeg Een aangepast domein toevoegen aan uw Front Door voor meer informatie.

Jokertekendomeinen

Jokertekendomeinen vereenvoudigen de configuratie van DNS-records en de routeringsconfiguratie van Azure Front Door-verkeer wanneer u een gedeeld stemdomein en tenantspecifieke subdomeinen gebruikt. Stel dat uw tenants toegang hebben tot hun toepassingen met behulp van subdomeinen zoals tenant1.app.contoso.com en tenant2.app.contoso.com. U kunt een domein met jokertekens configureren in *.app.contoso.complaats van elk tenantspecifiek domein afzonderlijk te configureren.

Azure Front Door biedt ondersteuning voor het maken van aangepaste domeinen die gebruikmaken van jokertekens. Vervolgens kunt u een route configureren voor aanvragen die binnenkomen in het domein met jokertekens. Wanneer u een nieuwe tenant onboardt, hoeft u uw DNS-servers niet opnieuw te configureren, nieuwe TLS-certificaten uit te geven of de configuratie van uw Azure Front Door-profiel bij te werken.

Jokertekendomeinen werken goed als u al uw verkeer naar één oorspronkelijke groep verzendt. Maar als u afzonderlijke stempels van uw oplossing hebt, is een domein met jokertekens op één niveau niet voldoende. U moet stemdomeinen met meerdere niveaus gebruiken of extra configuratie opgeven door bijvoorbeeld de routes te overschrijven die moeten worden gebruikt voor het subdomein van elke tenant. Zie Overwegingen bij het gebruik van domeinnamen in een multitenant-oplossing voor meer informatie.

Azure Front Door geeft geen beheerde TLS-certificaten uit voor jokertekendomeinen, dus u moet uw eigen certificaat kopen en leveren.

Zie Jokertekendomeinen voor meer informatie.

Beheerde TLS-certificaten

Het verkrijgen en installeren van TLS-certificaten kan complex en foutgevoelig zijn. En TLS-certificaten verlopen na een bepaalde periode, meestal één jaar, en moeten opnieuw worden uitgegeven en opnieuw worden geïnstalleerd om onderbreking van toepassingsverkeer te voorkomen. Wanneer u beheerde TLS-certificaten van Azure Front Door gebruikt, is Microsoft verantwoordelijk voor het uitgeven, installeren en vernieuwen van certificaten voor uw aangepaste domein.

Uw oorspronkelijke toepassing kan worden gehost op een andere Azure-service die ook beheerde TLS-certificaten biedt, zoals Azure-app Service. Azure Front Door werkt transparant met de andere service om uw TLS-certificaten te synchroniseren.

Als u uw tenants toestaat hun eigen aangepaste domeinen op te geven en u wilt dat Azure Front Door certificaten voor deze domeinnamen uitgeeft, moeten uw tenants geen CAA-records configureren op hun DNS-servers die ervoor kunnen zorgen dat Azure Front Door certificaten namens hen uitgeeft. Zie TLS/SSL-certificaten voor meer informatie.

Zie End-to-end TLS met Azure Front Door voor meer informatie over TLS-certificaten.

Routering

Een multitenant-toepassing kan een of meer toepassingsstempels hebben die de tenants dienen. Stempels worden vaak gebruikt om implementaties in meerdere regio's mogelijk te maken en ondersteuning te bieden voor het schalen van een oplossing naar een groot aantal tenants.

Azure Front Door heeft een krachtige set routeringsmogelijkheden die ondersteuning bieden voor een aantal multitenant-architecturen. U kunt routering gebruiken om verkeer tussen oorsprongen binnen een stempel te distribueren of om verkeer naar de juiste stempel voor een specifieke tenant te verzenden. U kunt routering configureren op basis van afzonderlijke domeinnamen, jokertekens en URL-paden. En u kunt de regelengine gebruiken om het routeringsgedrag verder aan te passen.

Zie overzicht van routeringsarchitectuur voor meer informatie.

Regelengine

U kunt de Azure Front Door-regelengine gebruiken om aan te passen hoe Aanvragen worden verwerkt in Azure Front Door aan de netwerkrand. Met de regelengine kunt u kleine logicablokken uitvoeren binnen de Azure Front Door-aanvraagverwerkingspijplijn. U kunt de regelengine gebruiken om de routeringsconfiguratie voor een aanvraag te overschrijven. U kunt de regelengine ook gebruiken om elementen van de aanvraag te wijzigen voordat deze naar de oorsprong wordt verzonden en om bepaalde onderdelen van het antwoord te wijzigen voordat deze naar de client wordt geretourneerd.

Stel dat u een toepassingslaag met meerdere tenants implementeert waarin u ook tenantspecifieke subdomeinen met jokertekens gebruikt, zoals beschreven in de volgende voorbeeldscenario's. U kunt de regelengine gebruiken om de tenant-id uit het subdomein van de aanvraag te extraheren en toe te voegen aan een aanvraagheader. Met deze regel kan de toepassingslaag bepalen van welke tenant de aanvraag afkomstig is.

Zie Wat is de Azure Front Door-regelengine? voor meer informatie.

Voorbeeldscenario's

In de volgende voorbeeldscenario's ziet u hoe u verschillende multitenant-architecturen in Azure Front Door kunt configureren en hoe de beslissingen die u neemt van invloed kunnen zijn op uw DNS- en TLS-configuratie.

Veel multitenant-oplossingen implementeren het patroon Implementatiestempels. Wanneer u deze implementatiebenadering gebruikt, implementeert u doorgaans één gedeeld Azure Front Door-profiel en gebruikt u Azure Front Door om binnenkomend verkeer naar de juiste stempel te routeren. Dit implementatiemodel is het meest voorkomende en scenario's 1 tot en met 4 in dit artikel laten zien hoe u het kunt gebruiken om te voldoen aan een reeks vereisten.

In sommige situaties kunt u echter een Azure Front Door-profiel implementeren in elke zegel van uw oplossing. In scenario 5 wordt dit implementatiemodel beschreven.

Scenario 1: Door provider beheerd jokertekendomein, één stempel

Contoso bouwt een kleine multitenant-oplossing. Het bedrijf implementeert één stempel in één regio en die stempel dient alle tenants. Alle aanvragen worden doorgestuurd naar dezelfde toepassingsserver. Contoso heeft besloten om jokertekendomeinen te gebruiken voor alle tenants, zoals tenant1.contoso.com en tenant2.contoso.com.

Contoso implementeert Azure Front Door met behulp van deze configuratie:

Diagram that shows an Azure Front Door configuration that has a single custom domain, route, and origin group and a wildcard TLS certificate in Azure Key Vault.

DNS-configuratie

Eenmalige configuratie: Contoso configureert twee DNS-vermeldingen:

  • Een TXT-record met jokertekens voor *.contoso.com. Deze waarde wordt ingesteld op de waarde die is opgegeven door Azure Front Door tijdens het onboardingproces voor aangepaste domeinen.
  • Een CNAME-record met jokertekens, *.contoso.comdat is een alias voor het Azure Front Door-eindpunt van Contoso: contoso.z01.azurefd.net.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

TLS-configuratie

Eenmalige configuratie: Contoso koopt een TLS-certificaat met jokertekens, voegt dit toe aan een sleutelkluis en verleent Azure Front Door toegang tot de kluis.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

Azure Front Door-configuratie

Eenmalige configuratie: Contoso maakt een Azure Front Door-profiel en één eindpunt. Ze voegen één aangepast domein toe aan de naam *.contoso.com en koppelen hun TLS-certificaat met jokertekens aan de aangepaste domeinresource. Vervolgens configureren ze één origin-groep die één oorsprong voor de toepassingsserver bevat. Ten slotte configureren ze een route om het aangepaste domein te verbinden met de oorspronkelijke groep.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

Vergoedingen

  • Deze configuratie is relatief eenvoudig te configureren en biedt klanten url's van het merk Contoso.
  • De benadering ondersteunt een groot aantal tenants.
  • Wanneer een nieuwe tenant wordt geïmplementeerd, hoeft Contoso geen wijzigingen aan te brengen in Azure Front Door-, DNS- of TLS-certificaten.

Nadelen

  • Deze benadering kan niet eenvoudig worden geschaald buiten één toepassingsstempel of -regio.
  • Contoso moet een TLS-certificaat met jokertekens kopen en het certificaat vernieuwen en installeren wanneer het verloopt.

Scenario 2: Door provider beheerd jokertekendomein, meerdere stempels

Proseware bouwt een multitenant-oplossing voor meerdere stempels die zijn geïmplementeerd in zowel Australië als Europa. Alle aanvragen binnen één regio worden geleverd met het stempel in die regio. Net als Contoso heeft Proseware besloten om jokertekendomeinen te gebruiken voor alle tenants, zoals tenant1.proseware.com en tenant2.proseware.com.

Proseware implementeert Azure Front Door met behulp van deze configuratie:

Diagram that shows an Azure Front Door configuration that has multiple custom domains, routes, and origin groups and a wildcard TLS certificate in Key Vault.

DNS-configuratie

Eenmalige configuratie: Proseware configureert twee DNS-vermeldingen:

  • Een TXT-record met jokertekens voor *.proseware.com. Deze waarde wordt ingesteld op de waarde die is opgegeven door Azure Front Door tijdens het onboardingproces voor aangepaste domeinen.
  • Een CNAME-record met jokertekens, *.proseware.comdat is een alias voor het Azure Front Door-eindpunt van Proseware: proseware.z01.azurefd.net.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

TLS-configuratie

Eenmalige configuratie: Proseware koopt een TLS-certificaat met jokertekens, voegt het toe aan een sleutelkluis en verleent Azure Front Door toegang tot de kluis.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

Azure Front Door-configuratie

Eenmalige configuratie: Proseware maakt een Azure Front Door-profiel en één eindpunt. Het bedrijf configureert meerdere oorsprongsgroepen, één per toepassingsstempel/-server in elke regio.

Wanneer een nieuwe tenant wordt toegevoegd: Proseware voegt een aangepaste domeinresource toe aan Azure Front Door. Ze gebruiken de naam *.proseware.com en koppelen hun TLS-certificaat met jokertekens aan de aangepaste domeinresource. Vervolgens maken ze een route om op te geven naar welke oorsprongsgroep (stempel) de aanvragen van de tenant moeten worden omgeleid. In het voorgaande diagram tenant1.proseware.com routeert u naar de oorspronkelijke groep in de regio Australië en tenant2.proseware.com routeert u naar de oorspronkelijke groep in de regio Europa.

Vergoedingen

  • Wanneer er nieuwe tenants worden onboarding uitgevoerd, zijn er geen DNS- of TLS-configuratiewijzigingen vereist.
  • Proseware onderhoudt één exemplaar van Azure Front Door om verkeer te routeren naar meerdere stempels in meerdere regio's.

Nadelen

  • Proseware moet Azure Front Door telkens wanneer er een nieuwe tenant wordt geïmplementeerd, opnieuw configureren.
  • Proseware moet aandacht besteden aan quota en limieten van Azure Front Door, met name op het aantal routes en aangepaste domeinen en de limiet voor samengestelde routering.
  • Proseware moet een TLS-certificaat met jokertekens kopen.
  • Proseware is verantwoordelijk voor het vernieuwen en installeren van het certificaat wanneer het verloopt.

Scenario 3: Door provider beheerde, op zegels gebaseerde jokertekensubdomeinen

Fabrikam bouwt een multitenant-oplossing. Het bedrijf implementeert stempels in Australië en de Verenigde Staten. Alle aanvragen binnen één regio worden verwerkt door de stempel in die regio. Fabrikam maakt gebruik van stemdomeinen op basis van stempels, zoals tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comen tenant3.us.fabrikam.com.

Het bedrijf implementeert Azure Front Door met behulp van deze configuratie:

Diagram that shows an Azure Front Door configuration that has multiple custom stamp-based stem domains, routes, origin groups, and wildcard TLS certificate in Key Vault.

DNS-configuratie

Eenmalige configuratie: Fabrikam configureert de volgende twee DNS-vermeldingen voor jokertekens voor elke stempel.

  • Een TXT-record met jokertekens voor elke stempel: *.australia.fabrikam.com en *.us.fabrikam.com. Ze worden ingesteld op de waarden die zijn opgegeven door Azure Front Door tijdens het onboardingproces van het aangepaste domein.
  • Een CNAME-record met jokertekens voor elke stempel *.australia.fabrikam.com en *.us.fabrikam.com, die beide aliassen zijn voor het Azure Front Door-eindpunt: fabrikam.z01.azurefd.net.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

TLS-configuratie

Eenmalige configuratie: Fabrikam koopt een TLS-certificaat met jokertekens voor elke stempel, voegt deze toe aan een sleutelkluis en verleent Azure Front Door toegang tot de kluis.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

Azure Front Door-configuratie

Eenmalige configuratie: Fabrikam maakt een Azure Front Door-profiel en één eindpunt. Ze configureren een oorsprongsgroep voor elke stempel. Ze maken aangepaste domeinen, met behulp van een jokerteken, voor elk subdomein op basis van een stempel: *.australia.fabrikam.com en *.us.fabrikam.com. Ze maken een route voor het aangepaste domein van elke stempel om verkeer naar de juiste oorspronkelijke groep te verzenden.

Wanneer een nieuwe tenant wordt onboarded: er is geen aanvullende configuratie vereist.

Vergoedingen

  • Met deze benadering kan Fabrikam grote aantallen tenants schalen op meerdere stempels.
  • Wanneer er nieuwe tenants worden onboarding uitgevoerd, zijn er geen DNS- of TLS-configuratiewijzigingen vereist.
  • Fabrikam onderhoudt één exemplaar van Azure Front Door om verkeer te routeren naar meerdere stempels in meerdere regio's.

Nadelen

  • Omdat URL's een structuur met meerdere onderdelen gebruiken, kunnen URL's complexer zijn voor gebruikers om mee te werken.
  • Fabrikam moet meerdere TLS-certificaten met jokertekens kopen.
  • Fabrikam is verantwoordelijk voor het vernieuwen en installeren van de TLS-certificaten wanneer ze verlopen.

Scenario 4: Vanity-domeinen

Adventure Works Cycles bouwt een multitenant-oplossing. Het bedrijf implementeert stempels in meerdere regio's, zoals Australië en de Verenigde Staten. Alle aanvragen binnen één regio worden verwerkt door de stempel in die regio. Adventure Works stelt de tenants in staat hun eigen domeinnamen mee te nemen. Tenant 1 kan bijvoorbeeld een aangepaste domeinnaam configureren, zoals tenant1app.tenant1.com.

Het bedrijf implementeert Azure Front Door met behulp van deze configuratie:

Diagram that shows an Azure Front Door configuration that has multiple custom vanity domains, routes, and origin groups and a combination of TLS certificates in Key Vault and TLS certificates that are managed by Azure Front Door.

DNS-configuratie

Eenmalige configuratie: Geen.

Wanneer een nieuwe tenant wordt geïmplementeerd: de tenant moet twee records maken op een eigen DNS-server:

  • Een TXT-record voor domeinvalidatie. Tenant 1 moet bijvoorbeeld een TXT-record met de naam tenant1app.tenant1.com configureren en deze instellen op de waarde die is opgegeven door Azure Front Door tijdens het onboardingproces van het aangepaste domein.
  • Een CNAME-record die is gealiaseerd naar het Azure Front Door-eindpunt van Adventure Works. Tenant 1 moet bijvoorbeeld een CNAME-record met de naam tenant1app.tenant1.com configureren en toewijzen aan adventureworks.z01.azurefd.net.

TLS-configuratie

Adventure Works en de tenants moeten bepalen wie TLS-certificaten uitgeeft:

  • De eenvoudigste optie is om Azure Front Door te gebruiken om de certificaten uit te geven en te beheren, maar tenants mogen geen CCA-records op hun DNS-servers configureren. Als dat het gebeurt, kunnen de records verhinderen dat de Azure Front Door-certificeringsinstantie certificaten uitgeeft.
  • Tenants kunnen ook hun eigen certificaten opgeven. Ze moeten samenwerken met Adventure Works om het certificaat te uploaden naar een sleutelkluis en toegang te bieden tot Azure Front Door.

Azure Front Door-configuratie

Eenmalige configuratie: Adventure Works maakt een Azure Front Door-profiel en één eindpunt. Ze configureren een oorsprongsgroep voor elke stempel. Ze maken geen aangepaste domeinresources of routes.

Wanneer een nieuwe tenant wordt toegevoegd: Adventure Works voegt een aangepaste domeinresource toe aan Azure Front Door. Ze gebruiken de door de tenant geleverde domeinnaam en koppelen het juiste TLS-certificaat aan de aangepaste domeinresource. Vervolgens maken ze een route om op te geven naar welke oorsprongsgroep (stempel) de aanvragen van de tenant moeten worden omgeleid. In het voorgaande diagram tenant1app.tenant1.com wordt u doorgestuurd naar de oorspronkelijke groep in de regio Australië en tenant2app.tenant3.com wordt deze doorgestuurd naar de oorspronkelijke groep in de regio VS.

Vergoedingen

  • Klanten kunnen hun eigen domeinnamen opgeven. Azure Front Door routeert aanvragen transparant naar de multitenant-oplossing.
  • Adventure Works onderhoudt één exemplaar van Azure Front Door om verkeer te routeren naar meerdere stempels in meerdere regio's.

Nadelen

  • Adventure Works moet Azure Front Door telkens opnieuw configureren wanneer een nieuwe tenant wordt geïmplementeerd.
  • Tenants moeten betrokken zijn bij het onboardingproces. Ze moeten DNS-wijzigingen aanbrengen en mogelijk TLS-certificaten uitgeven.
  • Tenants beheren hun DNS-records. Wijzigingen in DNS-records kunnen van invloed zijn op de mogelijkheid om toegang te krijgen tot de Adventure Works-oplossing.
  • Adventure Works moet letten op quota en limieten van Azure Front Door, met name op het aantal routes en aangepaste domeinen, en de limiet voor samengestelde routering.

Scenario 5: Azure Front Door-profiel per stempel

U kunt voor elke stempel een Azure Front Door-profiel implementeren. Als u 10 stempels hebt, implementeert u 10 exemplaren van Azure Front Door. Deze aanpak kan handig zijn als u de beheertoegang van de Azure Front Door-configuratie van elke stempel wilt beperken. Het kan ook handig zijn als u meerdere Azure Front Door-profielen moet gebruiken om te voorkomen dat resourcequota of limieten worden overschreden.

Tip

Azure Front Door is een wereldwijde resource. Zelfs als u regionale stempels implementeert, wordt elk Azure Front Door-profiel wereldwijd gedistribueerd. U moet overwegen of u echt meerdere Azure Front Door-profielen moet implementeren en welke voordelen u hiermee krijgt.

Als u een stempel hebt dat meerdere tenants bedient, moet u overwegen hoe u verkeer naar elke tenant routeert. Bekijk de benaderingen die in de voorgaande scenario's worden beschreven en overweeg om benaderingen te combineren die aan uw vereisten voldoen.

Vergoedingen

  • Als u uw configuratie uitbreidt over meerdere profielen, bereikt u minder waarschijnlijk de resourcelimieten van Azure Front Door. Als u bijvoorbeeld een groot aantal aangepaste domeinen wilt ondersteunen, kunt u de domeinen verdelen over meerdere Azure Front Door-profielen en binnen de grenzen van elk profiel blijven.
  • Met deze aanpak kunt u de machtigingen voor resourcebeheer van Azure Front Door instellen. U kunt op rollen gebaseerd toegangsbeheer van Azure (RBAC) gebruiken om beheerders toegang te verlenen tot één stempelprofiel.

Nadelen

  • Bij deze benadering worden doorgaans hoge kosten in rekening gebracht omdat u meer profielen implementeert. Zie Inzicht in Front Door-facturering voor meer informatie.
  • Er is een limiet voor het aantal Azure Front Door-profielen dat u in één Azure-abonnement kunt implementeren. Zie Quota en limieten van Front Door voor meer informatie.
  • U moet het Azure Front Door-profiel van elke stempel afzonderlijk configureren en u moet dns-configuratie, TLS-certificaten en TLS-configuratie voor elke stempel beheren.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

  • Raj Nemani | Directeur, Partner Technology Strategist
  • John Downs | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen