Distribuera Horizon på Azure VMware Solution

Anteckning

Det här dokumentet fokuserar på produkten VMware Horizon, tidigare känt som Horizon 7. Horizon är en annan lösning än Horizon Cloud i Azure, även om det finns vissa delade komponenter. Viktiga fördelar med Azure VMware Solution är både en enklare storleksmetod och integrering av VMware Cloud Foundation-hantering i Azure Portal.

VMware Horizon®, en plattform för virtuella skrivbord och program, körs i datacentret och ger enkel och centraliserad hantering. Den levererar virtuella skrivbord och program på valfri enhet, var som helst. Med Horizon kan du skapa och hantera anslutningar till Windows och virtuella Linux-skrivbord, fjärrskrivbordsserver (RDS) som är värdar för program, stationära datorer och fysiska datorer.

Här fokuserar vi specifikt på att distribuera Horizon på Azure VMware Solution. Allmän information om VMware Horizon finns i produktionsdokumentationen för Horizon:

Med Horizons introduktion på Azure VMware Solution finns det nu två VDI-lösningar (Virtual Desktop Infrastructure) på Azure-plattformen. I följande diagram sammanfattas de viktigaste skillnaderna på en hög nivå.

Diagram som visar skillnaderna mellan Horizon på Azure VMware Solution och Horizon Cloud på Azure.

Horizon 2006 och senare versioner på versionsraden Horizon 8 stöder både lokal och Azure VMware Solution distribution. Det finns några Horisont-funktioner som stöds lokalt men inte på Azure VMware Solution. Andra produkter i Ekosystemet i Horizon stöds också. Mer information finns i funktionsparitet och samverkan.

Distribuera Horizon i ett hybridmoln

Du kan distribuera Horizon i en hybridmolnmiljö med hjälp av Horizon Cloud Pod Architecture (CPA) för att sammankoppla lokala datacenter och Azure-datacenter. CPA skalar upp distributionen, skapar ett hybridmoln och tillhandahåller redundans för affärskontinuisering och haveriberedskap. Mer information finns i Expandera befintliga Horisont 7-miljöer.

Viktigt

CPA är inte en utsträckt distribution; varje Horizon-podd är distinkt och alla anslutningsservrar som tillhör var och en av de enskilda poddarna måste finnas på en enda plats och köras på samma broadcast-domän ur ett nätverksperspektiv.

Precis som lokalt eller privat datacenter kan du distribuera Horizon i ett Azure VMware Solution privat moln. Vi diskuterar viktiga skillnader i distributionen av Horizon lokalt och Azure VMware Solution i följande avsnitt.

Det privata Azure-molnet är konceptuellt samma som VMware SDDC, en term som vanligtvis används i Horizon-dokumentationen. Resten av det här dokumentet använder båda termerna synonymt.

Horizon Cloud Connector krävs för att Horizon Azure VMware Solution hantera prenumerationslicenser. Du kan distribuera Cloud Connector i Azure Virtual Network tillsammans med Horizon-anslutningsservrar.

Viktigt

Horizon Control Plane-stöd för Horizon on Azure VMware Solution är inte tillgängligt ännu. Se till att ladda ned VHD-versionen av Horizon Cloud Connector.

Rollen molnadministratör för vCenter

Eftersom Azure VMware Solution är en SDDC-tjänst och Azure hanterar livscykeln för SDDC på Azure VMware Solution begränsas vCenter-behörighetsmodellen på Azure VMware Solution design.

Kunder måste använda rollen Molnadministratör, som har en begränsad uppsättning vCenter-behörigheter. The Horizon product was modified to work with the Cloud Admin role on Azure VMware Solution, specifically:

  • Etablering av omedelbar klon har ändrats för att köras Azure VMware Solution.

  • En specifik vSAN-princip (VMware_Horizon) skapades på Azure VMware Solution för att fungera med Horizon, som måste vara tillgänglig och användas i de SDDCs som distribueras för Horizon.

  • vSphere Content-Based Read Cache (CBRC), även kallat View Storage Accelerator, inaktiveras när den körs på Azure VMware Solution.

Viktigt

CBRC får inte aktiveras igen.

Anteckning

Azure VMware Solution konfigurerar automatiskt specifika Inställningar för Horisont så länge du distribuerar Horizon 2006 (även kallat Horizon 8) och högre på grenen Horizon 8 och väljer Azure-alternativet i installationsprogrammet för Horizon-anslutningsservern.

Horizon på Azure VMware Solution distributionsarkitektur

En typisk arkitekturdesign för Horizon använder en podd- och blockstrategi. Ett block är ett enda vCenter, medan flera block tillsammans gör en podd. En Horisont-podd är en organisationsenhet som bestäms av Scalability Limits (Skalbarhetsgränser för Horizon). Varje Horizon-podd har en separat hanteringsportal, så en standarddesignmetod är att minimera antalet poddar.

Varje moln har ett eget nätverksschema för nätverksanslutning. I kombination med VMware SDDC-nätverk/NSX Edge ger Azure VMware Solution-nätverksanslutningen unika krav för distribution av Horizon som skiljer sig från den lokala.

Varje privat Azure-moln och SDDC kan hantera 4 000 skrivbords- eller programsessioner, förutsatt att:

  • Arbetsbelastningstrafiken överensstämmer med loginVSI-arbetsprofilen.

  • Endast protokolltrafik beaktas, inga användardata.

  • NSX Edge är konfigurerat för att vara stort.

Anteckning

Din arbetsbelastningsprofil och dina behov kan vara olika, och därför kan resultatet variera beroende på ditt användningsfall. Användardatavolymer kan sänka skalningsgränserna i kontexten för din arbetsbelastning. Ändra storlek på och planera distributionen därefter. Mer information finns i riktlinjerna för storleksändring i avsnittet Size Azure VMware Solution hosts for Horizon deployments (Storlek på Azure VMware Solution värdar för Horizon-distributioner).

Med tanke på den högsta gränsen för privat Azure-moln och SDDC rekommenderar vi en distributionsarkitektur där Horizon-anslutningsservrarna och VMware Unified Access Gateways (UAG:er) körs i Azure Virtual Network. Det omvandlar effektivt varje privat Azure-moln och SDDC till ett block. Maximera i sin tur skalbarheten för Horizon som körs på Azure VMware Solution.

Anslutningen från Azure Virtual Network till privata Azure-moln/SDDC:er ska konfigureras med ExpressRoute FastPath. I följande diagram visas en grundläggande distribution av Horizon-podden.

Diagram som visar den typiska distributionen av Horizon-podden med ExpressPath Fast Path.

Nätverksanslutning för skalning av Horizon på Azure VMware Solution

Det här avsnittet innehåller nätverksarkitekturen på en hög nivå med några vanliga distributionsexempel som hjälper dig att skala Upp Horisont på Azure VMware Solution. Fokus ligger särskilt på kritiska nätverkselement.

Single Horizon-podd på Azure VMware Solution

Diagram som visar en enda Horizon-podd Azure VMware Solution.

En enda Horizon-podd är det mest enkla distributionsscenariot eftersom du bara distribuerar en Horizon-podd i regionen USA, östra. Eftersom varje privat moln och SDDC uppskattas hantera 4 000 skrivbordssessioner distribuerar du den maximala poddstorleken i Horizon. Du kan planera distributionen av upp till tre privata moln/SDDCs.

Med De virtuella Datorerna i Horizon-infrastrukturen som distribuerats i Azure Virtual Network kan du nå de 12 000 sessionerna per Horisont-podd. Anslutningen mellan varje privat moln och SDDC till Azure Virtual Network expressroute snabb sökväg. Ingen öst-väst-trafik mellan privata moln behövs.

Viktiga antaganden för det här grundläggande distributionsexempel är att:

  • Du har ingen lokal Horizon-podd som du vill ansluta till den här nya podden med hjälp av Cloud Pod Architecture (CPA).

  • Slutanvändare ansluter till sina virtuella skrivbord via Internet (jämfört med att ansluta via ett lokalt datacenter).

Du ansluter AD-domänkontrollanten i Azure Virtual Network med din lokala AD via VPN- eller ExpressRoute-krets.

En variant av det grundläggande exemplet kan vara att stödja anslutning för lokala resurser. Användare kan till exempel komma åt stationära datorer och generera trafik för virtuella skrivbordsprogram eller ansluta till en lokal Horizon-podd med CPA.

Diagrammet visar hur du stöder anslutning för lokala resurser. Om du vill ansluta till företagsnätverket till Azure Virtual Network behöver du en ExpressRoute-krets. Du måste också ansluta företagets nätverk till vart och ett av de privata molnet och SDDC:er med hjälp av ExpressRoute-Global Reach. Den tillåter anslutning från SDDC till ExpressRoute-kretsen och lokala resurser.

Diagram som visar anslutningen av ett företagsnätverk till en Azure-Virtual Network.

Poddar med flera horisonter Azure VMware Solution flera regioner

Ett annat scenario är skalning av Horizon över flera poddar. I det här scenariot distribuerar du två Horizon-poddar i två olika regioner och federerar dem med hjälp av CPA. Det liknar nätverkskonfigurationen i föregående exempel, men med några ytterligare korsregionala länkar.

Du ansluter Azure-Virtual Network i varje region till de privata molnen/SDDC:erna i den andra regionen. Det gör att Horizon-anslutningsservrar som ingår i CPA-federation kan ansluta till alla datorer som hanteras. Om du lägger till extra privata moln/SDDC:er i den här konfigurationen kan du skala till totalt 24 000 sessioner.

Samma principer gäller om du distribuerar två Horizon-poddar i samma region. Se till att distribuera den andra Horizon-podden i en separat Azure-Virtual Network. Precis som i exemplet med en enda podd kan du ansluta ditt företagsnätverk och din lokala podd till det här exemplet med flera poddar/regioner med ExpressRoute och Global Reach.

 Diagram som visar flera Horizon-poddar Azure VMware Solution flera regioner.

Storlek Azure VMware Solution värdar för Horizon-distributioner

Horizons storleksmetod för en värd som körs i Azure VMware Solution är enklare än Horisont lokalt. Det beror på att Azure VMware Solution värden är standardiserad. Den exakta värdändringen hjälper dig att avgöra antalet värdar som behövs för att stödja dina VDI-krav. Det är centralt för att fastställa kostnaden per skrivbord.

Ändra storlek på tabeller

Specifika vCPU/vRAM-krav för virtuella Horizon-skrivbord beror på kundens specifika arbetsbelastningsprofil. Ta hjälp av ditt MSFT- och VMware-säljteam för att fastställa dina vCPU/vRAM-krav för dina virtuella skrivbord.

vCPU per virtuell dator vRAM per virtuell dator (GB) Instans 100 virtuella datorer 200 virtuella datorer 300 virtuella datorer 400 virtuella datorer 500 virtuella datorer 600 virtuella datorer 700 virtuella datorer 800 virtuella datorer 900 virtuella datorer 1 000 virtuella datorer 2 000 virtuella datorer 3 000 virtuella datorer 4 000 virtuella datorer 5 000 virtuella datorer 6 000 virtuella datorer 6 400 virtuella datorer
2 3.5 AVS 3 3 4 4 5 6 6 7 8 9 17 25 33 41 49 53
2 4 AVS 3 3 4 5 6 6 7 8 9 9 18 26 34 42 51 54
2 6 AVS 3 4 5 6 7 9 10 11 12 13 26 38 51 62 75 79
2 8 AVS 3 5 6 8 9 11 12 14 16 18 34 51 67 84 100 106
2 12 AVS 4 6 9 11 13 16 19 21 23 26 51 75 100 124 149 158
2 16 AVS 5 8 11 14 18 21 24 27 30 34 67 100 133 165 198 211
4 3.5 AVS 3 3 4 5 6 7 8 9 10 11 22 33 44 55 66 70
4 4 AVS 3 3 4 5 6 7 8 9 10 11 22 33 44 55 66 70
4 6 AVS 3 4 5 6 7 9 10 11 12 13 26 38 51 62 75 79
4 8 AVS 3 5 6 8 9 11 12 14 16 18 34 51 67 84 100 106
4 12 AVS 4 6 9 11 13 16 19 21 23 26 51 75 100 124 149 158
4 16 AVS 5 8 11 14 18 21 24 27 30 34 67 100 133 165 198 211
6 3.5 AVS 3 4 5 6 7 9 10 11 13 14 27 41 54 68 81 86
6 4 AVS 3 4 5 6 7 9 10 11 13 14 27 41 54 68 81 86
6 6 AVS 3 4 5 6 7 9 10 11 13 14 27 41 54 68 81 86
6 8 AVS 3 5 6 8 9 11 12 14 16 18 34 51 67 84 100 106
6 12 AVS 4 6 9 11 13 16 19 21 23 26 51 75 100 124 149 158
6 16 AVS 5 8 11 14 18 21 24 27 30 34 67 100 133 165 198 211
8 3.5 AVS 3 4 6 7 9 10 12 14 15 17 33 49 66 82 98 105
8 4 AVS 3 4 6 7 9 10 12 14 15 17 33 49 66 82 98 105
8 6 AVS 3 4 6 7 9 10 12 14 15 17 33 49 66 82 98 105
8 8 AVS 3 5 6 8 9 11 12 14 16 18 34 51 67 84 100 106
8 12 AVS 4 6 9 11 13 16 19 21 23 26 51 75 100 124 149 158
8 16 AVS 5 8 11 14 18 21 24 27 30 34 67 100 133 165 198 211

Horisontens storlek på indata

Det här behöver du samla in för din planerade arbetsbelastning:

  • Antal samtidiga skrivbord

  • Obligatorisk vCPU per skrivbord

  • Obligatoriskt vRAM per skrivbord

  • Nödvändig lagring per skrivbord

I allmänhet är VDI-distributioner antingen CPU- eller RAM-begränsade, vilket avgör värdstorleken. Låt oss ta följande exempel för en LoginVSI Knowledge Worker-typ av arbetsbelastning som verifierats med prestandatestning:

  • 2 000 samtidig skrivbordsdistribution

  • 2vCPU per skrivbord.

  • 4 GB vRAM per skrivbord.

  • 50 GB lagringsutrymme per skrivbord

I det här exemplet är det totala antalet värdar ut till 18, vilket ger en vm-per-värd-densitet på 111.

Viktigt

Kundens arbetsbelastningar varierar från det här exemplet på en LoginVSI Knowledge Worker. Som en del av att planera distributionen kan du arbeta med dina VMware EUC SE:er för dina specifika storleks- och prestandabehov. Se till att köra din egen prestandatestning med hjälp av den faktiska planerade arbetsbelastningen innan du slutför värdändringen och justera därefter.

Horizon om Azure VMware Solution licensiering

Det finns fyra komponenter till de totala kostnaderna för att köra Horizon Azure VMware Solution.

Azure VMware Solution kapacitetskostnad

Information om prissättningen finns på Azure VMware Solution sidan med priser

Licenskostnad för Horizon

Det finns två tillgängliga licenser för användning med Azure VMware Solution, som kan vara antingen samtidig användare (CCU) eller namngiven användare (NU):

  • Prenumerationslicens för Horizon

  • Universal-prenumerationslicens för Horizon

Om du bara distribuerar Horizon Azure VMware Solution inom en överskådlig framtid ska du använda Horizon-prenumerationslicensen eftersom det är en lägre kostnad.

Om den distribueras Azure VMware Solution lokalt väljer du 555 000 000 prenumerationer som ett användningsfall för haveriberedskap. Den innehåller dock en vSphere-licens för lokal distribution, så den har en högre kostnad.

Ta hjälp av säljteamet för VMware EUC för att fastställa licenskostnaden för Horizon baserat på dina behov.

Azure-instanstyper

Information om storlekar på virtuella Azure-datorer som krävs för Horizon-infrastrukturen finns i Horizon-installation på Azure VMware Solution.

Referenser

Systemkrav för Horizon Agent för Linux

Nästa steg

Mer information om VMware Horizon på Azure VMware Solution finns i vanliga frågor och svar om VMware Horizon.