Självstudie: Skapa ett kommersiellt redo Azure Remote Rendering-program

  • Artikel

I den här självstudien lär du dig:

  • Sessionshantering för kommersiella program
  • Spåra sessioner för fakturering
  • Optimera användarupplevelsen kring sessionsinläsningstid
  • Överväganden kring nätverksfördröjning

Förutsättningar

Introduktion till kommersiell beredskap

Azure Remote Rendering utökar vad som är möjligt med mixad verklighet. När grunderna har integrerats i din lösning finns det ett antal ytterligare överväganden för att säkerställa att din lösning är säker, skalbar och redo att leverera värde.

Den här modulen beskriver några ytterligare funktioner som du kan behöva tänka på för ditt kommersiella program.

En bred översikt över metodtips för systemomfattande arkitektur finns i:

Rapporter

Integrering av analysverktyg kan hjälpa dig att hantera, spåra och förbättra din lösning.

En omfattande lista över de analysresurser som är tillgängliga finns i:

Spåra användning för fakturering

Att spåra användningen av Azure Remote Rendering av flera interna team eller externa klienter blir ett viktigt övervägande, särskilt i situationer med flera klientorganisationer.

För att uppnå detta erbjuder Azure en tjänst som kallas resurstaggning, som associerar förbrukningen av Azure Remote Rendering-tjänsten med varje klient.

Om du vill ha mer information om namngivning och taggning av resurser är ett bra ställe att börja på:

Diagnostik

Kraftfulla verktyg som Händelsespårning för Windows (ETW) och Loggning av händelsespårning (ETL) gör det enkelt att generera spårningshändelser i ditt program och kan hjälpa dig att diagnostisera nätverk, innehållsinmatning, session, program och andra problem som kan uppstå i en kommersiell lösningsdistribution.

Mer information finns här:

Användningsanalys

Azure Application Insights hjälper dig att förstå hur personer använder ditt Azure Remote Rendering-program. Varje gång du uppdaterar din app kan du utvärdera hur bra den fungerar för användarna och förbättra din lösning i enlighet med detta. Med den här kunskapen kan du fatta datadrivna beslut om dina nästa utvecklingscykler.

Mer information finns här:

Strategier för snabb starttid

Ditt användningsfall kan kräva snabb start från programstart till 3D-modellvisning. Till exempel under ett viktigt möte där det är viktigt att allt körs i förväg. Ett annat exempel är under en CAD 3D-modellgranskning där snabb design iteration mellan ett CAD-program och mixad verklighet är nyckeln till effektivitet.

Azure Remote Rendering kräver förbearbetade 3D-modeller, och Azure tar för närvarande flera minuter att skapa en session och läsa in en modell för rendering. Att göra den här processen så smidig och snabb som möjligt kräver förberedelse av 3D-modelldata och ARR-sessionen i förväg.

De förslag som delas här är för närvarande inte en del av standardversionen av Azure Remote Rendering, men du kan implementera dem på egen hand för snabbare starttider.

Initiera tidigt

För att minska starttiden är den enklaste lösningen att flytta skapandet och initieringen av sessionen så tidigt som möjligt i användararbetsflödet. En strategi är att initiera sessionen så snart det är känt att en ARR-session kommer att behövas. Det här är ofta när användaren börjar ladda upp en 3D-modell till Azure Blob Storage som ska användas med Azure Remote Rendering. I det här fallet kan skapande och initiering av sessioner initieras samtidigt som 3D-modelluppladdningen så att båda arbetsströmmarna körs parallellt.

Den här processen kan effektiviseras ytterligare genom att se till att de valda Azure Blob Storage-indata- och utdatacontainrarna finns i samma regionala datacenter som Azure Remote Rendering-sessionen.

Schemaläggning

Om du vet att du har ett framtida behov av Azure Remote Rendering kan du schemalägga ett visst datum och en viss tid för att starta Azure Remote Rendering-sessionen.

Det här alternativet kan erbjudas via en webbportal där personer både kan ladda upp en 3D-modell och schemalägga en tid för att visa den i framtiden. Detta skulle också vara ett bra ställe att be om andra inställningar som Standard - eller Premium-rendering . Premiumrendering kan vara lämpligt om det finns en önskan att visa en blandning av tillgångar där den ideala storleken är svårare att bestämma automatiskt eller ett behov av att se till att Azure-regionen har virtuella datorer tillgängliga vid den angivna tidpunkten.

Sessionspooler

I de mest krävande situationerna är ett annat alternativ sessionspooler, där en eller flera sessioner skapas och initieras hela tiden. Detta skapar en sessionspool för omedelbar användning av en begärande användare. Nackdelen med den här metoden är att när den virtuella datorn har initierats startar faktureringen för tjänsten. Det kanske inte är kostnadseffektivt att hålla en sessionspool igång hela tiden, men baserat på analys kan det vara möjligt att förutsäga belastningstoppar eller kombineras med schemaläggningsstrategin ovan för att förutsäga när sessioner kommer att behövas och rampa upp och ned sessionspoolen i enlighet med detta.

Den här strategin hjälper också till att optimera valet mellan Standard - och Premium-sessioner på ett mer dynamiskt sätt eftersom det skulle gå mycket snabbare att växla mellan de två typerna i en enskild användarsession, till exempel det fall där en Premium-komplexitetsmodell visas först, följt av en som kan fungera inom Standard. Om dessa användarsessioner är ganska långa kan det finnas betydande kostnadsbesparingar.

Mer information om Azure Remote Rendering-sessioner finns i:

Routningsstrategier för standard- och Premium-serverstorlek

Att behöva välja om du vill skapa en Standard - eller Premium-serverstorlek är en utmaning när du utformar användarupplevelsen och systemet från slutpunkt till slutpunkt. Även om det är ett alternativ att bara använda Premium-sessioner använder Standard-sessioner mycket mindre Azure-beräkningsresurser och är billigare än Premium. Detta ger en stark motivation att använda Standard-sessioner när det är möjligt och endast använda Premium när det behövs.

Här delar vi flera alternativ, från minst till mest omfattande, för att hantera önskan att hantera sessionsval.

Använd endast Standard eller Premium

Om du är säker på att dina behov alltid kommer att ligga under tröskelvärdet mellan Standard och Premium förenklar detta ditt beslut avsevärt. Använd bara Standard. Tänk dock på att påverkan på användarupplevelsen är betydande om den totala komplexiteten för de inlästa tillgångarna avvisas som för komplex för en Standard-session .

På samma sätt, om du förväntar dig att en stor del av användningarna överskrider tröskelvärdet mellan Standard och Premium, eller om kostnaden inte är en nyckelfaktor i ditt användningsfall, är det också ett alternativ att alltid välja Premium för att hålla det enkelt.

Fråga användaren

Om du vill stödja både Standard och Premium är det enklaste sättet att avgöra vilken typ av session som ska instansiera att be användaren när de väljer 3D-tillgångar att visa. Utmaningen med den här metoden är att den kräver att användaren förstår komplexiteten hos 3D-tillgången eller till och med flera tillgångar som ska visas. Detta rekommenderas vanligtvis inte av den anledningen. Om användaren väljer fel och väljer Standard kan den resulterande användarupplevelsen komprometteras vid ett olämpligt tillfälle.

Analysera 3D-modellen

En annan relativt enkel metod är att analysera komplexiteten hos de valda 3D-tillgångarna. Om modellkomplexiteten ligger under tröskelvärdet för Standard startar du en Standard-session , annars initierar du en Premium-session . Här är utmaningen att en enskild session i slutändan kan användas för att visa flera modeller där vissa kan överskrida komplexitetströskeln för en Standard-session , vilket resulterar i att det inte går att sömlöst använda samma session för en sekvens med olika 3D-tillgångar.

Automatisk växling

Automatisk växling mellan Standard - och Premium-sessioner kan vara mycket meningsfullt i en systemdesign som även innehåller sessionspooler. Den här strategin möjliggör ytterligare optimering av resursutnyttjande. När användaren läser in modeller för visning bestäms komplexiteten och rätt sessionsstorlek begärs från sessionspooltjänsten.

Arbeta med nätverk

Diagnostik

Azure Remote Rendering kräver en snabb Internetanslutning med låg svarstid. Kvaliteten på användarens nätverk kan ha en betydande inverkan på upplevelsens kvalitet. Med tanke på att dina klienter sannolikt har olika nätverkskonfigurationer och endast ibland dålig nätverksfördröjning är diagnostikverktyg viktiga.

För att säkerställa att du kan leverera en konsekvent högkvalitativ upplevelse rekommenderar vi att du integrerar analysverktyg på serversidan och klientsidan i dina Azure Remote Rendering-program. Detta beväpnar dig med den information du behöver för att diagnostisera och minimera eventuella nätverksproblem som dina klienter kan uppleva.

Klientnätverkskonfigurationer

En av de största utmaningarna med att utveckla robusta samarbetslösningar som distribueras till en mängd olika företagsmiljöer är att förberedas för olika nätverkstopologier och företagsbrandväggskonfigurationer som dina klienter kan använda.

Många företag blockerar all peer-to-peer-trafik inom ett LAN. Detta gör det svårt att dra nytta av enkelheten och det smidiga användargränssnittet för automatisk LAN-identifiering för att upprätta en lokal delad session mellan alla identifierade instanser av ditt mixed reality-program.

Andra potentiella felpunkter är routrar som konfigurerats för att avsiktligt begränsa bandbredd och brandväggar som blockerar de flesta TCP/IP-portar.

När du planerar att använda Azure Remote Rendering i ett okänt nätverk rekommenderar vi följande:

  • Ange en checklista före mötet för att utvärdera nätverksberedskapen.
  • Se till att rätt regionalt datacenter kan hantera begäran.
  • Tillåt gott om tid för att diagnostisera eventuella problem.
  • Ta med en mobil hotspot med en dataplan med hög bandbredd som säkerhetskopia.

Bandbredd från slutpunkt till slutpunkt

Det är viktigt att utvärdera bandbreddsfunktionerna för varje del av nätverket som kan finnas mellan den virtuella Azure Remote Rendering-datorn och slutklienten. Tänk på att nätverkssegmentet från Azure-datacentret till klientens ISP kan vara mer av en begränsande faktor än från ISP till klienten. Hastighetstestet för blobnedladdning kan användas för att diagnostisera sådana problem.

Bandbreddskonkurrens

När du utformar programmet för mixad verklighet bör du tänka på att olika funktioner i appen kan konkurrera med Azure Remote Rendering om bandbredd. Det mest sannolika oväntade exemplet är när många deltagare i ett enda rum alla förväntar sig att samtidigt använda ARR för att visa en 3D-tillgång. Varje del av nätverksdataflödet måste ha kapacitet för att transportera summan av alla ARR-dataströmmar tillsammans.

Andra exempel är strömmad video, samtidiga bakgrundsuppladdningar av annat relaterat innehåll och röstchatt, särskilt där det finns många deltagare och systemet använder en distribuerad peer-to-peer-metod i stället för en ljudblandningsserver i mittenmetoden.

Mer information om nätverksanalys finns i:

Samarbetsöverväganden

Några av de mest värdefulla användningsområdena för Azure Remote Rendering omfattar samarbete mellan flera deltagare som visar samma 3D-upplevelse samtidigt. I dessa delade sessioner är det viktigt att känna igen att varje deltagare behöver en unik Azure Remote Rendering-session, oavsett om de finns på samma plats i samma nätverk eller inte.

Detta är sant eftersom varje deltagare faktiskt ser samma upplevelse från olika utsiktspunkter, vilket kräver att samma 3D-tillgångar återges från vart och ett av dessa perspektiv samtidigt.

Flera Fjärrrenderingssessioner i Azure

Om du har för avsikt att stödja delade upplevelser med Azure Remote Rendering måste de system som du har infört för att skapa och hantera ARR-sessioner vara beredda att initiera flera sessioner. Dessa sessioner kan behöva initieras i olika Azure-datacenter om deltagarna är geografiskt spridda.

Systemet måste också hantera möjligheten att en eller flera av deltagarna kan vara i en geografisk region som för närvarande inte stöds av Azure Remote Rendering eller för närvarande inte har några azure remote rendering VM-instanser tillgängliga.

Den här hanteringen av flera samtidiga sessioner kan effektiviseras ytterligare i kombination med sessionspooler och andra strategier som beskrivs i det här dokumentet.

Överväganden för Azure Blob Storage

Alla samtidiga ARR-sessioner kan referera till samma SAS-URI för den konverterade modellen som ska visas. Detta gör det möjligt att ladda upp och konvertera önskade 3D-tillgångar en gång och sedan dela dem över alla sessioner. Detta gäller särskilt när deltagarna är samlokala och använder samma datacenter där det inte finns några prestandaproblem relaterade till att Azure Blob Storage finns i ett annat datacenter än Azure Remote Rendering-servern och användaren.

Om 3D-tillgångar vanligtvis laddas upp för en enda visningssession och sedan ignoreras, till exempel i en designgranskningssession, är den geografiska regionen för Azure Blob Storage i förhållande till Azure Remote Rendering-servern också mindre kritisk.

Men för 3D-tillgångar som används upprepade gånger, till exempel i ett träningsanvändningsfall, rekommenderar vi att du behåller färdiga 3D-tillgångar i bloblagring i varje regionalt datacenter där du planerar att använda Azure Remote Rendering. Detta kan automatiseras med hjälp av Azure Storage-redundans. CDN används ofta även för detta ändamål, men det här är ännu inte ett alternativ för Azure Remote Rendering.

Mer information:

Hantera modellåtkomst

Om du använder Azure Remote Rendering fullt ut måste du noga överväga infrastrukturen från slutpunkt till slutpunkt för att hantera 3D-modeller.

En fördel med att använda Azure Remote Rendering är att stora 3D-tillgångar aldrig behöver överföras direkt till enheten för mixad verklighet innan de visas. När en 3D-tillgång har laddats upp och konverterats för användning med Azure Remote Rendering kan dessutom valfritt antal användare dela den enskilda instansen av 3D-modellen.

Överväganden för 3D-modellåtkomst

Här följer några viktiga överväganden när du bestämmer dig för din strategi för modellåtkomst.

Baserat på det förväntade användningsfallet avgör du den bästa platsen eller kombinationen av platser så att en användare kan välja 3D-tillgångarna för visning. Några vanliga alternativ är:

  • Direkt inom mixad verklighetsupplevelse
  • Via en tillhörande webbportal
  • I ett tillhörande skrivbord eller mobilprogram

Om ditt användningsfall har användningsmönster där samma 3D-tillgång kan laddas upp flera gånger, spårar serverdelen vilka modeller som redan har konverterats för användning med ARR så att en modell bara bearbetas i förväg en gång för flera framtida val. Ett exempel på designgranskning skulle vara när ett team har åtkomst till en vanlig ursprunglig 3D-tillgång. Varje teammedlem förväntas granska modellen med hjälp av ARR någon gång i sin arbetsström. Endast den första vyn utlöser sedan förbearbetningssteget. De efterföljande vyerna skulle leta upp den associerade efterbearbetade filen i SAS-utdatacontainern.

Beroende på användningsfallet vill du förmodligen fastställa och eventuellt spara rätt Serverstorlek för Azure Remote Rendering, Standard eller Premium, för varje 3D-tillgång eller grupp av tillgångar som visas tillsammans i samma session.

Urvalslista för enhetsmodell

I många användningsfall, till exempel en utbildning, uppgiftsvägledning eller ett marknadsföringsprogram, kan uppsättningen med 3D-tillgångar som ofta visas i Azure Remote Rendering vara ganska statisk. I dessa situationer kan en kuraterad uppsättning 3D-tillgångar förkonverteras och göras tillgänglig via en databas som innehåller nödvändig information för att fylla i en urvalslista över kurerade tillgångar. Dessa data kan sedan hämtas från mixed reality-programmet för att fylla i en markeringsmeny.

Detta kan tas ett steg längre genom att även erbjuda ett sätt att ladda upp privata 3D-tillgångar som är unika för varje individ eller grupp. Den här listan över privata tillgångar kan sedan kombineras med listan över vanliga, kurerade tillgångar i användarupplevelsen för att välja 3D-tillgångar att visa.

OneDrive-åtkomst på enheten

Med tanke på att en OneDrive-filväljare är inbyggd i Microsofts enheter för mixad verklighet är det tilltalande att välja 3D-tillgångar på enheten från OneDrive, särskilt för användningsfall där det är vanligt att läsa in olika eller ändrade 3D-modeller. I det här scenariot skulle användaren välja en eller flera 3D-tillgångar via OneDrive-filväljaren i ditt mixed reality-program. 3D-tillgångarna migreras sedan till en SAS-indatacontainer, konverteras till en SAS-utdatacontainer och kopplas till ARR-sessionen. Helst anropar programmet för mixad verklighet en molnbaserad process för att utföra de här stegen i stället för att flytta alla bitar från OneDrive till enheten och tillbaka ned till Azure Blob Storage.

Den här metoden kan tas ett steg längre genom att bevara en association mellan 3D-tillgångar som tidigare har visats så att när samma modell väljs igen från OneDrive kan programmet kringgå konverteringsprocessen och läsa in den associerade konverterade 3D-tillgången direkt via sin SAS-URI.

Mer information:

Direkt CAD-åtkomst

Ett övertygande användningsfall för mixad verklighet är designgranskningar av CAD-arbete som pågår. I det här scenariot är den snabbaste inläsningstiden från skrivbord till mixad verklighet nyckeln. En idealisk lösning kan vara att utveckla plugin-program för specifika CAD-program. Dessa plugin-program skulle direkt hantera alla aspekter av belastnings-, konverterings- och visningsprocessen:

  • Ange ett UX för att:
    • Para ihop CAD-programmet med en specifik enhet för mixad verklighet (en gång).
    • Begär att den valda geometrin ska visas på enheten för mixad verklighet.
  • Om den inte redan körs startar du Azure Remote Rendering-sessionen så att den kan bearbetas parallellt vid uppladdning och konvertering av CAD-filen
  • Normalisera CAD-geometridata till ett av formaten som stöds av Azure Remote Rendering
  • Överföra normaliserade data direkt till Azure Blob Storage-indatacontainern
  • Initiera modellkonverteringsprocessen
  • Länka modellens SAS-URI för utdatacontainer till Azure Remote Rendering-sessionen
  • Meddela det kopplade mixed reality-programmet att modellen är tillgänglig och redo att visa och ange SAS-URI:n för utdatacontainern så att programmet kan koppla den till sessionen.

En mycket enklare men något mindre strömlinjeformad metod kan automatisera processen att spara 3D-modellen på en lokal hårddisk och sedan initiera en process för att överföra den sparade filen till SAS-indatacontainern.

Azure Marketplace

Många företagsklienter kräver att din Azure Stack kan distribueras under sina egna Azure-konton och autentiseringsuppgifter av säkerhetsskäl. För att göra detta möjligt bör du överväga att paketera ditt Azure-hanterade program så att det kan publiceras på Azure Marketplace som ett Azure-programerbjudande.

Mer information:

Säkerhet

Det är viktigt att skapa en azure-fjärrrenderingslösning från slutpunkt till slutpunkt för säkerhet från grunden. Det finns många säkerhetsaspekter att tänka på när du utformar din lösning från slutpunkt till slutpunkt, bland annat:

  • Autentiseringsstrategier
  • Åtkomsthantering – grupper, principer och behörigheter
  • Flera innehavare
  • Datalagring och överföringskryptering
  • Tillfälliga användningstoken
  • DDoS-attacker (Distributed Denial of Service)
  • Hotidentifiering
  • VPN:er och säkra nätverk
  • Brandväggar
  • Hantering av certifikat och hemliga nycklar
  • Sårbarhet och sårbarheter för program

För autentisering är det klokt att flytta så mycket av ARR-autentiseringen och sessionshanteringen till en Azure-webbtjänst som möjligt. Detta resulterar i en bättre hanterad och säkrare lösning.

Mer information: