Självstudie: Skapa ett kommersiellt Azure Remote Rendering program

  • Artikel
  • 14 minuter för att läsa

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 sessionens inläsningstid
  • Överväganden kring nätverksfördröjning

Förutsättningar

Introduktion till kommersiell beredskap

Azure Remote Rendering 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.

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

En bred översikt över metodtipsen för systemomfattande arkitektur finns här:

Analys

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 för dig finns här:

Spåra användning för fakturering

Det är viktigt att Azure Remote Rendering av flera interna team eller externa klienter, särskilt i situationer med flera innehavare.

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 kan du börja på följande sätt:

Diagnostik

Kraftfulla verktyg som ETW (Event Tracing for Windows) (ETW) och Händelsespårningsloggning (ETL) gör det enkelt att generera spårningshändelser i ditt program och kan hjälpa till att diagnostisera nätverk, innehållsinmatning, session, program och andra problem som kan uppstå i en distribution av en kommersiell lösning.

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 på motsvarande sätt. 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

Användningsfallet 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 är igång i förväg. Ett annat exempel är under en granskning av CAD 3D-modellen 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. För att göra den här processen så sömlös och snabb som möjligt krävs förberedelse av 3D-modelldata och ARR-session i förväg.

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

Starta 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. Detta är ofta när användaren börjar ladda upp en 3D-modell för att Azure Blob Storage att använda med Azure Remote Rendering. I det här fallet kan sessionsskapande och -initiering 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 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 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 både användare kan ladda upp en 3D-modell och schemalägga en tid för att visa den i framtiden. Det här är också en bra plats att fråga efter andra inställningar som Standard- eller Premium-rendering. Premium-rendering kan vara lämpligt om det finns en vilja att visa en blandning av tillgångar där den perfekta storleken är svårare att automatiskt fastställa eller ett behov av att se till att Azure-regionen har virtuella datorer tillgängliga vid den angivna tidpunkten.

Sessionspoolning

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 faktureringen för tjänsten startar när den virtuella datorn har initierats. 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 öka och minska sessionspoolen på motsvarande sätt.

Den här strategin hjälper också till med 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 enda användarsession, till exempel det fall där en Premium-komplexitetsmodell visas först, följt av en som kan fungera i Standard. Om dessa användarsessioner är långa kan det leda till betydande kostnadsbesparingar.

Mer information Azure Remote Rendering sessioner finns här:

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 ska utforma användarupplevelsen och hela systemet. Även om det är ett alternativ att endast använda Premium-sessioner så använder standardsessioner mycket mindre Azure-beräkningsresurser och är billigare än Premium. Detta ger en stark motivation att använda standardsessioner 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 sessionsval.

Använd endast Standard eller Premium

Om du är säker på att dina behov alltid kommer att understiga tröskelvärdet mellan Standard och Premium gör detta beslutet betydligt enklare. Använd bara Standard. Tänk 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 standardsession.

Om du förväntar dig att en stor del av användningsområdena ska överskrida tröskelvärdet mellan Standard och Premium, eller om kostnaden inte är en viktig faktor 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 ha stöd för både Standard och Premium är det enklaste sättet att avgöra vilken typ av session som ska instansieras att be användaren när de väljer 3D-tillgångar att visa. Utmaningen med den här metoden är att användaren måste förstå komplexiteten i 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 tillfälle.

Analysera 3D-modellen

En annan relativt enkel metod är att analysera komplexiteten hos de valda 3D-tillgångarna. Om modellens komplexitet ligger under tröskelvärdet för Standard initierar du en Standard-session, annars initierar du en Premium-session. Här är utmaningen att en enda session i slutändan kan användas för att visa flera modeller som vissa kan överskrida tröskelvärdet för komplexitet för en standardsession, 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 omfattar sessionspooler. Den här strategin möjliggör ytterligare optimering av resursutnyttjande. När användaren läser in modeller för visning fastställs 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 kort svarstid. Kvaliteten på användarens nätverk kan ha en betydande inverkan på kvaliteten på upplevelsen. Med tanke på att dina klienter troligen har olika nätverkskonfigurationer och bara ibland dålig nätverksfördröjning, är diagnostiska verktyg viktiga.

För att säkerställa att du kan leverera en konsekvent hög kvalitet rekommenderar vi att du integrerar analysverktyg på serversidan och på klientsidan i dina Azure Remote Rendering program. Om du gör det får du den information du behöver för att diagnostisera och åtgärda eventuella nätverksproblem som klienterna kan ha.

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 de olika nätverkstopologin och de företagsbrandväggskonfigurationer som klienterna kan använda.

Många företag blockerar all peer-to-peer-trafik i ett LAN. Detta gör det svårt att dra nytta av enkelheten och strömlinjeformade UX 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 bandbredden 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ätverkets beredskap.
  • Se till att lämpligt regionalt datacenter kan skicka begäran.
  • Ge tillräckligt med 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 end-to-end

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

Konkurrens om bandbredd

När du utformar programmet för mixad verklighet bör du komma ihåg att olika funktioner i appen kan konkurrera med Azure Remote Rendering för bandbredd. Det mest sannolika oväntade exemplet är när många deltagare i ett enda rum 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 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 när det finns många deltagare och systemet använder en distribuerad peer-to-peer-metod i stället för en ljudblandande server i mitten.

Mer information om nätverksanalys finns i:

Överväganden för samarbete

Några av de mest värdefulla användningsområdena Azure Remote Rendering att samarbeta mellan flera deltagare som visar samma 3D-upplevelse samtidigt. I dessa delade sessioner är det viktigt att känna till 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 utgångspunkter, vilket kräver att samma 3D-tillgångar återges från var och en av dessa perspektiv samtidigt.

Flera Azure Remote Rendering sessioner

Om du planerar att stödja delade upplevelser med Azure Remote Rendering måste de system som du inför för att skapa och hantera ARR-sessioner vara förberedda på 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 befinner sig i ett geografiskt område som för närvarande inte stöds av Azure Remote Rendering eller som 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.

Azure Blob Storage överväganden

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 den mellan alla sessioner. Detta gäller särskilt när deltagarna finns på samma plats och använder samma datacenter där det inte finns några prestandaproblem som rör Azure Blob Storage som 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 tas bort, till exempel i en designgranskningssession, är det geografiska området för Azure Blob Storage i förhållande till Azure Remote Rendering-servern också mindre kritiskt.

För 3D-tillgångar som ska användas upprepade gånger, till exempel i ett träningsfall, rekommenderar vi dock att du behåller 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 Azure Storage redundans. CDN används ofta även för det här ändamålet, men det är ännu inte ett alternativ för Azure Remote Rendering.

Mer information:

Hantera modellåtkomst

Att utnyttja Azure Remote Rendering helt och hållet kräver noggrann hänsyn till hela infrastrukturen för att hantera 3D-modeller.

En fördel med Azure Remote Rendering är att stora 3D-tillgångar aldrig behöver överföras direkt till enheten med 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 hur många användare som helst dela den enskilda instansen av 3D-modellen.

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

Här är några viktiga saker att tänka på när du bestämmer dig för din strategi för modellåtkomst.

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

  • Direkt i mixed reality-upplevelsen
  • Via en tillhörande webbportal
  • I ett tillhörande skrivbordsprogram eller mobilprogram

Om ditt användningsfall har användningsmönster där samma 3D-tillgång kan laddas upp flera gånger spårar backend-enheten vilka modeller som redan har konverterats för användning med ARR så att en modell endast förbearbetas en gång för flera framtida val. Ett designgranskningsexempel är när ett team har åtkomst till en gemensam ursprunglig 3D-tillgång. Varje teammedlem förväntas granska modellen med 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 efterbehandlade filen i SAS-utdatacontainern.

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

Urvalslista för modell på enheten

I många användningsfall, till exempel utbildning, vägledning för uppgifter eller marknadsföringsprogram, kan uppsättningen 3D-tillgångar som ofta visas i Azure Remote Rendering vara ganska statisk. I sådana fall kan en curated uppsättning 3D-tillgångar för konverteras och göras tillgänglig via en databas som innehåller nödvändig information för att fylla i en urvalslista över hanterade tillgångar. Dessa data kan sedan hämtas från programmet för mixad verklighet för att fylla i en urvalsmeny.

Detta kan tas ett steg längre genom att erbjuda ett sätt att ladda upp privata 3D-tillgångar, som är unika för varje individ eller grupp. Listan över privata tillgångar kan sedan kombineras med listan över vanliga, granskade 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 med mixad verklighet är det tilltalande att välja 3D-tillgångar på enheten från OneDrive, särskilt i användningsfall där det är vanligt att läsa in olika eller ändrade 3D-modeller. I det här scenariot väljer användaren en eller flera 3D-tillgångar via OneDrive-filväljaren i ditt mixed reality-program. 3D-tillgångarna skulle sedan migreras till en SAS-indatacontainer, konverteras till en SAS-utdatacontainer och kopplas till ARR-sessionen. Vi rekommenderar att programmet för mixad verklighet anropar en molnbaserad process för att utföra dessa steg i stället för att flytta alla bitar från OneDrive till enheten och tillbaka 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 direkt läsa in den associerade konverterade 3D-tillgången via dess SAS-URI.

Mer information:

Direkt CAD-åtkomst

Ett övertygande användningsfall för mixad verklighet är designgranskningar av PÅGÅENDE CAD-arbete. 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 inläsningen, konverteringen och visningsprocessen:

  • Ange ett UX för att:
    • Koppla CAD-programmet till en specifik enhet för mixad verklighet (en gång).
    • Begär att den valda geometrin visas på enheten med mixad verklighet.
  • Om den inte redan körs kör du Azure Remote Rendering-sessionen så att den kan bearbeta parallellt medan CAD-filen laddas upp och konverteras
  • Normalisera CAD-geometridata till något av de format 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 programmet med mixad verklighet att modellen är tillgänglig och redo för visning och ange SAS-URI:en för utdatacontainern så att programmet kan koppla den till sessionen.

En mycket enklare men något mindre effektiv metod kan automatisera processen med 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 måste kunna Azure Stack 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 Application erbjudande.

Mer information:

Säkerhet

Det är viktigt att du skapar en Azure Remote Rendering säkerhetslösning från grunden. Det finns många säkerhetsaspekter att tänka på när du utformar din lösning från end-to-end, till exempel:

  • Autentiseringsstrategier
  • Åtkomsthantering – grupper, principer och behörigheter
  • Flera innehavare
  • Datalagring och överföringskryptering
  • Tillfälliga användningstoken
  • Distribuerade doS-attacker (Denial of Service)
  • Hotidentifiering
  • VPN:er och säkra nätverk
  • Brandväggar
  • Hantering av certifikat och hemliga nycklar
  • Sårbarheter och sårbarheter i 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: