Deploy Horizon på Azure VMware-løsning

Deploy Horizon på Azure VMware-løsning

• 29/09/2020
• 11 minutter at læse
• • s
  • t

VMware Horizon®, en platform for virtuelle skriveborde og applikationer, kører i datacenteret og giver enkel og centraliseret administration. Den leverer virtuelle desktops og applikationer på enhver enhed, hvor som helst. Horizon giver dig mulighed for at oprette og formidle forbindelser til virtuelle Windows- og Linux-skriveborde, RDS-værtede programmer (Remote Desktop Server), skriveborde og fysiske maskiner.

Her fokuserer vi specifikt på implementering af Horizon på Azure VMware Solution. For generelle oplysninger om VMware Horizon henvises der til Horizon-produktionsdokumentationen:

• Hvad er VMware Horizon?

• Lær mere om VMware Horizon

• Horizon-referencearkitektur

Med introduktionen af Horizon på Azure VMware Solution er der nu to Virtual Desktop Infrastructure (VDI)-løsninger på Azure-platformen. Følgende diagram opsummerer de vigtigste forskelle på et højt niveau.

Horizon 2006 og senere versioner på Horizon 8-udgivelseslinjen understøtter både on-premises-implementering og implementering af Azure VMware Solution. Der er nogle få Horizon-funktioner, der understøttes på stedet, men ikke på Azure VMware Solution. Yderligere produkter i Horizon-økosystemet understøttes også. Du kan finde oplysninger under Funktionsparitet og interoperabilitet.

Deploy Horizon i en hybrid cloud

Du kan implementere Horizon i et hybrid cloud-miljø, når du bruger Horizon Cloud Pod Architecture (CPA) til at forbinde datacentre på stedet og Azure-datacentre. CPA opskalerer din implementering, opbygger en hybrid cloud og giver redundans til forretningskontinuitet og katastrofeberedskab. Du kan finde flere oplysninger under Udvidelse af eksisterende Horizon 7-miljøer.

I lighed med on-premises eller private datacentre kan Horizon implementeres i en privat cloud med Azure VMware Solution. Vi vil diskutere de vigtigste forskelle i forbindelse med implementering af Horizon på stedet og på Azure VMware Solution i de følgende afsnit.

Azure private cloud er konceptuelt set det samme som VMware SDDC, et begreb, der typisk anvendes i Horizon-dokumentationen. I resten af dette dokument anvendes udtrykkene Azure private cloud og VMware SDDC i flæng.

Horisont Cloud Connector er påkrævet for Horizon på Azure VMware Solution for at administrere abonnementslicenser. Cloud Connector kan implementeres i Azure Virtual Network sammen med Horizon-forbindelsesservere.

vCenter Cloud Admin-rolle

Da Azure VMware Solution er en SDDC-tjeneste, og Azure administrerer livscyklussen for SDDC på Azure VMware Solution, er vCenter-tilladelsesmodellen på Azure VMware Solution begrænset af design.

Kunderne skal bruge Cloud Admin-rollen, som har et begrænset sæt vCenter-tilladelser. Horizon-produktet blev ændret til at fungere med Cloud Admin-rollen på Azure VMware Solution, specifikt:

• Instant clone provisioning blev ændret til at kunne køre på Azure VMware Solution.

• En specifik vSAN-politik (VMware_Horizon) blev oprettet på Azure VMware Solution for at fungere med Horizon, som skal være tilgængelig og bruges i de SDDC’er, der er implementeret til Horizon.

• VSphere Content-Based Read Cache (CBRC), også kendt som View Storage Accelerator, er deaktiveret, når den kører på Azure VMware Solution.

Horizon på Azure VMware Solution-implementeringsarkitektur

Et typisk Horizon-arkitekturdesign anvender en pod- og blokstrategi. En blok er et enkelt vCenter, mens flere blokke tilsammen udgør en pod. En Horizon-pod er en organisationsenhed, der er bestemt af Horizon-skalerbarhedsgrænserne. Hver Horizon-pod har en separat administrationsportal, og derfor er en standarddesignpraksis at minimere antallet af pods.

Hver sky har sin egen netværksforbindelsesordning. Kombineret med VMware SDDC-netværk / NSX Edge udgør Azure VMware-løsningens netværksforbindelse unikke krav til implementering af Horizon, der adskiller sig fra onpremises.

Hver privat Azure-sky og SDDC kan håndtere 4.000 desktop- eller applikationssessioner, forudsat at:

• Arbejdsbelastningstrafikken flugter med LoginVSI-opgavearbejderprofilen.

• Kun protokoltrafik tages i betragtning, ingen brugerdata.

• NSX Edge er konfigureret til at være stor.

Givet Azures private cloud og SDDC-maksimumgrænsen anbefaler vi en implementeringsarkitektur, hvor Horizon Connection Servers og VMware Unified Access Gateways (UAG’er) kører inden for Azures virtuelle netværk. Det gør effektivt hver Azure-privat sky og SDDC til en blok. Derved maksimeres skalerbarheden af Horizon, der kører på Azure VMware Solution.

Forbindelsen fra Azure Virtual Network til Azure private skyer / SDDC’er bør konfigureres med ExpressRoute FastPath. Følgende diagram viser en grundlæggende Horizon-pod-implementering.

Netværksforbindelser til skalering af Horizon på Azure VMware Solution

Dette afsnit udlægger netværksarkitekturen på et højt niveau med nogle almindelige implementeringseksempler, der hjælper dig med at skalere Horizon på Azure VMware Solution. Fokus er specifikt på kritiske netværkselementer.

En enkelt Horizon-pod på Azure VMware Solution

En enkelt Horizon-pod er det mest ligefremme implementeringsscenarie, fordi du kun implementerer én Horizon-pod i US East-regionen. Da hver privat cloud og SDDC anslås at kunne håndtere 4.000 desktop-sessioner, implementerer du den maksimale Horizon-pod-størrelse. Du kan planlægge implementeringen af op til tre private skyer/SDDC’er.

Med de virtuelle maskiner (VM’er) i Horizon-infrastrukturen, der er implementeret i Azure Virtual Network, kan du nå op på 12.000 sessioner pr. Horizon-pod. Forbindelsen mellem hver privat sky og SDDC til Azure Virtual Network er ExpressRoute Fast Path. Der er ikke behov for øst-vest-trafik mellem private skyer.

Nøgleforudsætninger for dette grundlæggende implementeringseksempel omfatter følgende:

• Du har ikke en Horizon-pod på stedet, som du ønsker at forbinde til denne nye pod ved hjælp af Cloud Pod Architecture (CPA).

• Endbrugere opretter forbindelse til deres virtuelle desktops via internettet (vs. tilslutning via et datacenter på stedet).

Du forbinder din AD-domænecontroller i Azure Virtual Network med din AD på stedet via VPN eller ExpressRoute-kredsløb.

En variation af det grundlæggende eksempel kan være at understøtte tilslutningsmuligheder for ressourcer på stedet. F.eks. kan brugerne få adgang til skriveborde og generere trafik med virtuelle skrivebordsprogrammer eller oprette forbindelse til en Horizon-pod på stedet ved hjælp af CPA.

Diagrammet viser, hvordan du understøtter konnektivitet for ressourcer på stedet. Hvis du vil oprette forbindelse til dit virksomhedsnetværk til Azure Virtual Network, skal du bruge et ExpressRoute-kredsløb. Du skal også forbinde dit virksomhedsnetværk med hver af de private skyer og SDDC’er ved hjælp af ExpressRoute Global Reach. Det giver mulighed for konnektivitet fra SDDC’en til ExpressRoute-kredsløbet og lokale ressourcer.

Multiple Horizon-pods på Azure VMware Solution på tværs af flere regioner

Et andet scenarie er skalering af Horizon på tværs af flere pods. I dette scenarie implementerer du to Horizon-pods i to forskellige regioner og forbinder dem ved hjælp af CPA. Det svarer til netværkskonfigurationen i det foregående eksempel, men med nogle ekstra forbindelser på tværs af regionerne.

Du forbinder Azure Virtual Network i hver region med de private skyer/SDDC’er i den anden region. Det gør det muligt for Horizon-forbindelsesservere, der er en del af CPA-føderationen, at oprette forbindelse til alle de administrerede desktops. Hvis du tilføjer yderligere private skyer/SDDC’er til denne konfiguration, vil du kunne skalere til 24.000 sessioner i alt.

De samme principper gælder, hvis du implementerer to Horizon-pods i den samme region. Sørg for at distribuere den anden Horizon-pod i et separat Azure Virtual Network. Ligesom i eksemplet med den enkelte pod kan du forbinde dit virksomhedsnetværk og din lokale pod til dette eksempel med flere pods/regioner ved hjælp af ExpressRoute og Global Reach.

Dimensionering af værter i Azure VMware Solution til Horizon-implementeringer

Horizons dimensioneringsmetodologi på en vært, der kører i Azure VMware Solution, er enklere end Horizon på stedet. Det skyldes, at værten i Azure VMware Solution er standardiseret. Den nøjagtige værtsdimensionering hjælper med at bestemme det antal værter, der er nødvendige for at understøtte dine VDI-krav. Det er centralt for at bestemme omkostningerne pr. desktop.

Dimensioneringstabeller

Specifikke vCPU/vRAM-krav til virtuelle Horizon-desktops afhænger af kundens specifikke arbejdsbelastningsprofil. Samarbejd med dit MSFT- og VMware-salgsteam for at hjælpe med at bestemme dine vCPU/vRAM-krav til dine virtuelle desktops.

vCPU pr. VM	vRAM pr. VM (GB)	Instance		100 VM’er	200 VM’er	300 VM’er	400 VM’er	500 VM’er	600 VM’er	700 VM’er	800 VM’er	900 VM’er	1000 VM’er	2000 VM’er	3000 VM’er	4000 VM’er	5000 VM’er	6000 VM’er	6400 VM’er
2	3.5	AVS	3	3	4	4	4	5	6	6	7	8	9	17	25	33	41	49	53
2	4	AVS	3	3	3	4	5	6	6	7	8	9	9	9	18	26	34	42	51	54
2	6	AVS	3	4	5	6	6	7	9	10	11	12	13	26	38	51	62	75	79
2	8	AVS	3	5	6	8	9	11	11	12	14	16	18	34	51	67	84	100	106
2	12	AVS	4	4	6	9	11	13	16	19	21	23	26	51	75	100	124	149	158
2	16	AVS	5	8	11	11	14	18	21	24	27	30	34	67	100	133	165	198	211
4	3.5	AVS	3	3	4	5	6	7	7	8	9	10	11	22	33	44	55	66	70
4	4	AVS	3	3	3	4	5	6	7	8	9	10	11	22	33	44	55	66	70
4	6	AVS	3	4	5	6	6	7	9	10	11	12	13	26	38	51	62	75	79
4	8	AVS	3	5	6	8	9	11	11	12	14	16	18	34	51	67	84	100	106
4	12	AVS	4	4	6	9	11	13	16	19	21	23	26	51	75	100	124	149	158
4	16	AVS	5	8	11	11	14	18	21	24	27	30	34	67	100	133	165	198	211
6	3.5	AVS	3	4	5	6	7	9	9	10	11	13	14	27	41	54	68	81	86
6	4	AVS	3	3	4	5	6	7	9	10	11	13	14	27	41	54	68	81	86
6	6	AVS	3	4	5	6	6	7	9	10	11	13	14	27	41	54	68	81	86
6	8	AVS	3	5	6	8	9	11	11	12	14	16	18	34	51	67	84	100	106
6	12	AVS	4	4	6	9	11	13	16	19	21	23	26	51	75	100	124	149	158
6	16	AVS	5	8	11	11	14	18	21	24	27	30	34	67	100	133	165	198	211
8	3.5	AVS	3	4	6	7	9	9	10	12	14	15	17	33	49	66	82	98	105
8	4	AVS	3	4	4	6	7	9	10	12	14	15	17	33	49	66	82	98	105
8	6	AVS	3	4	6	7	9	9	10	12	14	15	17	33	49	66	82	98	105
8	8	AVS	3	5	5	6	8	9	11	12	14	16	18	34	51	67	84	100	106
8	12	AVS	4	6	9	11	11	13	16	16	19	21	23	26	51	75	100	124	149	158
8	16	AVS	5	5	8	11	14	18	21	24	27	30	34	67	100	133	165	198	211

Horizon sizing inputs

Her er, hvad du skal samle for din planlagte arbejdsbyrde:

• Antal samtidige desktops

• Nødvendig vCPU pr. desktop

• Nødvendig vRAM pr. desktop

• Nødvendig lagring pr. desktop

Generelt er VDI-implementeringer enten CPU- eller RAM-begrænset, hvilket bestemmer værtsstørrelsen. Lad os tage følgende eksempel på en arbejdsbyrde af LoginVSI Knowledge Worker-typen, der er valideret med test af ydeevne:

• 2.000 samtidige desktopimplementeringer

• 2vCPU pr. desktop.

• 4 GB vRAM pr. desktop.

• 50 GB lagerplads pr. desktop

For dette eksempel er det samlede antal værter faktorer ud til 18, hvilket giver en VM-per-host-tæthed på 111.

Horizon on Azure VMware Solution-licensering

Der er fire komponenter i de samlede omkostninger ved at køre Horizon on Azure VMware Solution.

Kapacitetsomkostninger for Azure VMware Solution

For oplysninger om prisfastsættelsen, se siden om prisfastsættelse for Azure VMware Solution

Horizon-licensomkostninger

Der er to tilgængelige licenser til brug med Azure VMware Solution, som enten kan være Concurrent User (CCU) eller Named User (NU):

• Horizon Subscription License

• Horizon Universal Subscription License

Hvis du kun implementerer Horizon på Azure VMware Solution inden for en overskuelig fremtid, skal du bruge Horizon Subscription License, da det er en lavere omkostning.

Hvis du implementerer Horizon på Azure VMware Solution og on-premises, som i forbindelse med en disaster recovery-brugssituation, skal du vælge Horizon Universal Subscription License. Den omfatter en vSphere-licens til udrulning på stedet, så den har en højere pris.

Samarbejd med dit VMware EUC-salgsteam for at bestemme Horizon-licensprisen baseret på dine behov.

Azure Instance Types

For at forstå størrelserne på de virtuelle Azure-maskiner, der vil være nødvendige for Horizon-infrastrukturen, henvises til VMwares retningslinjer, som kan findes her.