Dela via


Skala upp din Azure DevTest Labs-infrastruktur

Orkestrering av en lyckad implementering av DevTest Labs i företagsskala kräver övervägande av viktiga beslutspunkter och planering av en metod för snabb distribution och implementering av Azure DevTest Labs.

Den här artikeln beskriver viktiga beslutspunkter som du bör tänka på när du planerar implementeringen och tillhandahåller en rekommenderad metod för distribution.

Viktiga beslutspunkter

Innan du implementerar DevTest Labs i företagsskala finns det flera viktiga beslutspunkter. Att förstå dessa beslutspunkter på hög nivå hjälper en organisation med designbeslut i framtiden. Dessa punkter bör dock inte hindra en organisation från att starta ett konceptbevis.

De tre översta områdena för inledande uppskalningsplanering är:

  • Nätverk och säkerhet
  • Prenumerationstopologi
  • Roller och ansvar

Nätverk och säkerhet

Nätverk och säkerhet är hörnstenar för alla organisationer. En företagsomfattande distribution kräver en mycket djupare analys, men det finns ett minskat antal krav för att lyckas med ett konceptbevis. Några viktiga fokusområden är:

  • Azure-prenumeration – Om du vill distribuera DevTest Labs måste du ha åtkomst till en Azure-prenumeration med rätt behörighet att skapa resurser. Det finns flera sätt att få åtkomst till Azure-prenumerationer, inklusive en företagsavtal och Betala per användning. Mer information om hur du får åtkomst till en Azure-prenumeration finns i Licensiering av Azure för företaget.
  • Åtkomst till lokala resurser – Vissa organisationer kräver att deras resurser i DevTest Labs har åtkomst till lokala resurser. Du behöver en säker anslutning från din lokala miljö till Azure. Det är viktigt att konfigurera antingen en VPN- eller Azure ExpressRoute-anslutning innan du kommer igång. Mer information finns i Översikt över virtuella nätverk.
  • Andra säkerhetskrav – Andra säkerhetskrav som datorprinciper, åtkomst till offentliga IP-adresser, anslutning till Internet är scenarier som kan behöva granskas innan du implementerar ett konceptbevis.

Prenumerationstopologi

Prenumerationstopologi är en viktig designövervägande när du distribuerar DevTest Labs till Enterprise. Det är dock inte nödvändigt att befästa alla beslut förrän ett konceptbevis har slutförts. När du utvärderar antalet prenumerationer som krävs för en företagsimplementering finns det två extremiteter:

  • En prenumeration för hela organisationen
  • Prenumeration per användare

Därefter belyser vi fördelarna med varje metod.

En prenumeration

Ofta är metoden för en prenumeration inte hanterbar i ett stort företag. Om du begränsar antalet prenumerationer får du dock följande fördelar:

  • Prognostiseringskostnader för företag. Budgetering blir mycket enklare i en enda prenumeration eftersom alla resurser finns i en enda pool. Med den här metoden kan du fatta enklare beslut om när du ska utföra kostnadskontrollåtgärder vid en viss tidpunkt under en faktureringsperiod.
  • Hanterbarheten för virtuella datorer, artefakter, formler, nätverkskonfiguration, behörigheter och principer är enklare eftersom alla uppdateringar endast krävs i en prenumeration i stället för att göra uppdateringar i många prenumerationer.
  • Nätverksinsatser är enklare i en enda prenumeration för företag där lokal anslutning är ett krav. Anslut virtuella nätverk mellan prenumerationer (hub-spoke-modell), som krävs med tillagda prenumerationer, kräver mer konfiguration, hantering och IP-adressutrymmen.
  • Teamsamarbete är enklare när alla arbetar i samma prenumeration. Det är till exempel enklare att omtilldela en virtuell dator till en medarbetare eller dela gruppresurser.

Prenumeration per användare

En separat prenumeration per användare ger lika möjligheter till det alternativa spektrumet. Fördelarna med att ha många prenumerationer är:

  • Azure-skalningskvoter hindrar inte implementeringen. När det här skrivs tillåter Azure till exempel 200 lagringskonton per prenumeration. Det finns driftkvoter för de flesta tjänster i Azure (många kan anpassas, vissa kan inte). I den här modellen för en prenumeration per användare är det högst osannolikt att de flesta kvoter nås. Mer information om aktuella Azure-skalningskvoter finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar.
  • Återbetalningar till grupper eller enskilda utvecklare blir mycket enklare för organisationer att ta hänsyn till kostnader med hjälp av sin aktuella modell.
  • Ägarskap och behörigheter för DevTest Labs-miljöer är enkla. Du ger utvecklare åtkomst på prenumerationsnivå och de ansvarar till 100 % för allt, inklusive nätverkskonfiguration, labbprinciper och hantering av virtuella datorer.

I Enterprise kan det finnas tillräckligt med begränsningar för spektrumets ytterligheter. Därför kan du behöva konfigurera prenumerationer på ett sätt som hamnar mitt i dessa ytterligheter. Som bästa praxis bör målet för en organisation vara att använda det minsta möjliga antalet prenumerationer. Tänk på de framtvingande funktioner som ökar det totala antalet prenumerationer. För att upprepa är prenumerationstopologin viktig för en företagsdistribution av DevTest Labs, men bör inte fördröja ett konceptbevis. Det finns mer information i styrningsartikeln om hur du bestämmer prenumeration och labbkornighet i organisationen.

Roller och ansvar

Ett DevTest Labs-konceptbevis har tre primära roller med definierat ansvar – prenumerationsägare, DevTest Labs-ägare, DevTest Labs-användare och eventuellt deltagare.

  • Prenumerationsägare – Prenumerationsägaren har behörighet att administrera en Azure-prenumeration, inklusive tilldela användare, hantera principer, skapa och hantera nätverkstopologi och begära kvotökningar. Mer information finns i denna artikel.
  • DevTest Labs ägare – DevTest Labs-ägaren har fullständig administrativ åtkomst till labbet. Den här personen ansvarar för att lägga till/ta bort användare, hantera kostnadsinställningar, allmänna labbinställningar och andra VM-/artefaktbaserade uppgifter. En labbägare har också alla rättigheter för en DevTest Labs-användare.
  • DevTest Labs-användare – DevTest Labs-användaren kan skapa och använda de virtuella datorerna i labbet. Dessa personer har några minimala administrativa funktioner på virtuella datorer som de skapar (starta/stoppa/ta bort/konfigurera sina virtuella datorer). Användarna kan inte hantera virtuella datorer för andra användare.

Dirigera implementeringen av DevTest Labs

Det här avsnittet innehåller en rekommenderad metod för snabb distribution och implementering av Azure DevTest Labs. I följande bild betonas den övergripande processen som normativ vägledning samtidigt som flexibilitet observeras för att stödja olika branschkrav och scenarier.

Diagram showing steps for implementing Azure DevTest Labs.

Antaganden

Den här artikeln förutsätter att du har följande objekt på plats innan du implementerar en DevTest Labs-pilot:

  • Azure-prenumeration: Pilotteamet har åtkomst till att distribuera resurser till en Azure-prenumeration. Om arbetsbelastningarna bara är utveckling och testning rekommenderar vi att du väljer Enterprise DevTest-erbjudandet för ytterligare tillgängliga avbildningar och lägre priser på virtuella Windows-datorer.
  • Lokal åtkomst: Vid behov har lokal åtkomst redan konfigurerats. Den lokala åtkomsten kan utföras via en PLATS-till-plats-VPN-anslutning eller via Express Route. Anslut ivity via Express Route kan vanligtvis ta många veckor att upprätta rekommenderar vi att expressvägen är på plats innan projektet startas.
  • Pilotteam: De initiala utvecklingsprojektteamen som använder DevTest Labs har identifierats tillsammans med tillämpliga utvecklings- eller testaktiviteter och fastställer krav/mål/mål för dessa team.

Milstolpe 1: Upprätta inledande nätverkstopologi och design

Det första fokusområdet när du distribuerar en Azure DevTest Labs-lösning är att upprätta den planerade anslutningen för de virtuella datorerna. Följande steg beskriver de nödvändiga procedurerna:

  1. Definiera inledande IP-adressintervall som har tilldelats till DevTest Labs-prenumerationen i Azure. Det här steget kräver prognostisering av förväntad användning i antal virtuella datorer så att du kan tillhandahålla ett tillräckligt stort block för framtida expansion.
  2. Identifiera metoder för önskad åtkomst till DevTest Labs (till exempel extern/intern åtkomst). En viktig punkt i det här steget är att avgöra om virtuella datorer har offentliga IP-adresser (dvs. direkt tillgängliga från Internet).
  3. Identifiera och upprätta anslutningsmetoder med resten av Azure-molnmiljön och lokalt. Om den framtvingade routningen med Express Route är aktiverad är det troligt att de virtuella datorerna behöver lämpliga proxykonfigurationer för att passera företagets brandvägg.
  4. Om virtuella datorer ska vara domänanslutna avgör du om de ansluter till en molnbaserad domän (till exempel Microsoft Entra Directory Services) eller en lokal domän. För lokalt avgör du vilken organisationsenhet (OU) i active directory som de virtuella datorerna ansluter till. Bekräfta dessutom att användarna har åtkomst till anslutning (eller upprätta ett tjänstkonto som har möjlighet att skapa datorposter i domänen)

Milstolpe 2: Distribuera pilotlabbet

När nätverkstopologin är på plats kan det första/pilotlabbet skapas genom att följa stegen nedan:

  1. Skapa en inledande DevTest Labs-miljö.
  2. Fastställa tillåtna VM-avbildningar och storlekar för användning med labb. Bestäm om anpassade avbildningar kan laddas upp till Azure för användning med DevTest Labs.
  3. Skydda åtkomsten till labbet genom att skapa en inledande rollbaserad åtkomstkontroll i Azure (Azure RBAC) för labbet (labbägare och labbanvändare). Vi rekommenderar att du använder synkroniserade Active Directory-konton med Microsoft Entra-ID för identitet med DevTest Labs.
  4. Konfigurera DevTest Labs för att använda principer som scheman, kostnadshantering, anspråksbara virtuella datorer, anpassade avbildningar eller formler.
  5. Upprätta en onlinelagringsplats, till exempel Azure Repos/Git.
  6. Besluta om användning av offentliga eller privata lagringsplatser eller kombination av båda. Organisera JSON-mallar för distributioner och långsiktig underhåll.
  7. Skapa anpassade artefakter om det behövs. Steget är valfritt.

Milstolpe 3: Dokumentation, support, inlärning och förbättring

De första pilotteamen kan kräva djupgående stöd för att komma igång. Använd deras erfarenheter för att säkerställa att rätt dokumentation och support finns på plats för fortsatt distribution av Azure DevTest Labs.

  1. Presentera pilotteamen för deras nya DevTest Labs-resurser (demonstrationer, dokumentation)
  2. Baserat på pilotteamens erfarenheter planerar och levererar du dokumentation efter behov
  3. Formalisera processen för registrering av nya team (skapa och konfigurera labb, ge åtkomst osv.)
  4. Baserat på det inledande upptaget kontrollerar du att den ursprungliga prognosen för IP-adressutrymmet fortfarande är rimlig och korrekt
  5. Se till att lämpliga efterlevnads- och säkerhetsgranskningar har slutförts

Nästa steg

Se nästa artikel i den här serien: Styrning av Azure DevTest Labs-infrastruktur