Distribuera Horizon på Azure VMware Solution

Kommentar

Det här dokumentet fokuserar på VMware Horizon-produkten, som tidigare kallades 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-lösningen är både en enklare storleksmetod och integrering av programvarudefinierat datacenter (SDDC) för privat molnhantering i Azure-portalen.

VMware Horizon®, en plattform för virtuellt skrivbord och program, körs i datacentret och tillhandahåller enkel och centraliserad hantering. Den levererar virtuella skrivbord och program på valfri enhet, var som helst. Med Horizon kan du skapa och asynkrona anslutningar till virtuella Windows- och Linux-skrivbord, fjärrskrivbordsserver (RDS) värdbaserade 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 horizon-produktionsdokumentationen:

• Vad är VMware Horizon?

• Läs mer om VMware Horizon

• Referensarkitektur för Horisont

Med Horizons introduktion till Azure VMware Solution finns det nu två VDI-lösningar (Virtual Desktop Infrastructure) på Azure-plattformen:

• VMware Horizon på Azure VMware Solution

• VMware Horizon Cloud (Desktop-as-a-Service Model)

Horizon 2006 och senare versioner på Horizon 8-versionsraden har stöd för distribution av både lokal lösning och Azure VMware Solution. Det finns några Horizon-funktioner som stöds lokalt men inte på Azure VMware Solution. Andra produkter i Horizon-ekosystemet 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 ansluta lokala datacenter och Azure-datacenter. CPA skalar upp distributionen, skapar ett hybridmoln och ger redundans för affärskontinuitet och haveriberedskap. Mer information finns i Expandera befintliga Horizon 7-miljöer.

Viktigt!

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

Precis som lokala eller privata datacenter kan du distribuera Horizon i ett privat Azure VMware Solution-moln. I följande avsnitt går vi igenom de viktigaste skillnaderna i distributionen av Horizon lokalt och Azure VMware Solution.

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

Horizon Cloud-Anslut or krävs för att Horizon på Azure VMware Solution ska kunna hantera prenumerationslicenser. Du kan distribuera Cloud Anslut or i Azure Virtual Network tillsammans med Horizon Anslut ion-servrar.

Viktigt!

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

vCenter Server Cloud Admin-roll

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

Kunder måste använda rollen Molnadministratör, som har en begränsad uppsättning vCenter Server-behörigheter. Horizon-produkten ändrades för att fungera med rollen Molnadministratör i Azure VMware Solution, särskilt:

• Omedelbar klontablering ändrades för att köras på Azure VMware Solution.

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

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

Viktigt!

CBRC får inte aktiveras igen.

Kommentar

Azure VMware Solution konfigurerar automatiskt specifika Horizon-inställningar så länge du distribuerar Horizon 2006 (Horizon 8) och senare på Horizon 8-grenen och väljer Azure-alternativet i installationsprogrammet för Horizon Anslut ion Server.

Distributionsarkitektur för Horizon på Azure VMware Solution

En typisk Horizon-arkitekturdesign använder en podd- och blockstrategi. Ett block är en enda vCenter Server, medan flera block tillsammans gör en podd. En Horizon-podd är en organisationsenhet som bestäms av Horizons skalbarhetsgränser. Varje Horizon-podd har en separat hanteringsportal, så en standarddesignmetod är att minimera antalet poddar.

Varje moln har ett eget nätverksanslutningsschema. Kombinera det med VMware NSX innebär nätverksanslutningen för Azure VMware Solution unika krav för att distribuera Horizon som skiljer sig från lokalt.

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

• Arbetsbelastningstrafiken överensstämmer med loginVSI-aktivitetsarbetsprofilen.

• Endast protokolltrafik beaktas, inga användardata.

• NSX Edge är konfigurerat att vara stort.

Kommentar

Din arbetsbelastningsprofil och dina behov kan skilja sig åt, och därför kan resultatet variera beroende på ditt användningsfall. Användardatavolymer kan sänka skalningsgränserna i samband med din arbetsbelastning. Ändra storlek på och planera distributionen i enlighet med detta. Mer information finns i riktlinjerna för storleksändring i avsnittet Storleksanpassa Azure VMware Solution-värdar för Horizon-distributioner .

Med tanke på maxgränsen för Azures privata moln och SDDC rekommenderar vi en distributionsarkitektur där Horizon Anslut ion Servers 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. I sin tur maximerar du skalbarheten för Horizon som körs på Azure VMware Solution.

Anslutningen från Azure Virtual Network till de privata Azure-molnen/SDDC:erna ska konfigureras med ExpressRoute-Anslut ions (FastPath aktiverat). Följande diagram visar en grundläggande Horizon-podddistribution.

Nätverksanslutning för att skala Horizon på Azure VMware Solution

Det här avsnittet beskriver nätverksarkitekturen på hög nivå med några vanliga distributionsexempel som hjälper dig att skala Horizon på Azure VMware Solution. Fokus ligger specifikt på kritiska nätverkselement.

Single Horizon-podd i Azure VMware Solution

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

Med de virtuella datorerna i Horizon-infrastrukturen (VM) distribuerade i Azure Virtual Network kan du nå de 12 000 sessionerna per Horizon-podd. Anslutningen mellan varje privat moln och SDDC till Azure Virtual Network är en ExpressRoute-Anslut ion (FastPath-aktiverad). Ingen öst-västlig trafik mellan privata moln behövs.

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

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

• Slutanvändarna 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-kretsen.

En variant av det grundläggande exemplet kan vara att stödja anslutning för lokala resurser. Användare får till exempel åtkomst till skrivbord och genererar trafik för program för virtuella skrivbord eller ansluter till en lokal Horizon-podd med hjälp av CPA.

Diagrammet visar hur du stöder anslutning för lokala resurser. För att ansluta till företagets nätverk till Azure Virtual Network behöver du en ExpressRoute-krets. Du måste ansluta företagets nätverk till vart och ett av de privata molnen och SDDDCs med hjälp av ExpressRoute Global Reach. Det tillåter anslutningen från SDDC till ExpressRoute-kretsen och lokala resurser.

Flera Horizon-poddar i Azure VMware Solution i flera regioner

Ett annat scenario är skalning av Horisont ö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 fler korsregionala länkar.

Anslut Det virtuella Azure-nätverket i varje region till de privata molnen/SDDC:erna i den andra regionen. Det gör att Horizon-anslutningsservrar som en del av CPA-federationen kan ansluta till alla skrivbord 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 ett separat virtuellt Azure-nätverk. Precis som i det enskilda poddexemplet kan du ansluta företagets nätverk och lokala podd till det här exemplet med flera poddar/regioner med ExpressRoute och Global Reach.

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

Horizons storleksmetodik på en värd som körs i Azure VMware Solution är enklare än Horizon lokalt. Det är enklare eftersom Azure VMware Solution-värden är standardiserad. Exakt storlek på värden hjälper dig att fastställa 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.

Storlekstabeller

Specifika vCPU/vRAM-krav för virtuella Horizon-skrivbord beror på kundens specifika arbetsbelastningsprofil. Arbeta med säljteamet för MSFT och VMware 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	6400 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

Horisontstorleksindata

Här är vad du behöver 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 verifieras med prestandatestning:

• 2 000 samtidiga skrivbordsdistributioner

• 2vCPU per skrivbord.

• 4 GB vRAM per skrivbord.

• 50 GB lagringsutrymme per skrivbord

I det här exemplet räknar 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 planeringen av distributionen kan du arbeta med dina VMware EUC SEs för dina specifika storleks- och prestandabehov. Se till att köra dina egna prestandatester med den faktiska planerade arbetsbelastningen innan du slutför värdstorleken och justerar därefter.

Horizon på Azure VMware Solution-licensiering

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

Kapacitetskostnad för Azure VMware-lösning

Information om priser finns på sidan med priser för Azure VMware Solution

Horizon-licensieringskostnad

Det finns två tillgängliga licenser för användning med Azure VMware-lösningen, som kan vara antingen Samtidig användare (CCU) eller Namngiven användare (NU):

• Horizon-prenumerationslicens

• Horizon Universal-prenumerationslicens

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

Om den distribueras i Azure VMware Solution och lokalt väljer du Horizon Universal Subscription License som ett haveriberedskapsanvändarfall. Den innehåller dock en vSphere-licens för lokal distribution, så den har en högre kostnad.

Arbeta med ditt VMware EUC-säljteam för att fastställa Horizon-licenskostnaden baserat på dina behov.

Azure-instanstyper

Information om de 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 i Azure VMware Solution finns i vanliga frågor och svar om VMware Horizon.