EKLIENT STANDARD SESSIONSHANTERING 1.0
eklient standard Sessionshantering 1 av 14 Historik Datum Version Av Förändring 2014-01-27 0.1 Olof Mårtensson Skapat dokumentstruktur 2014-02-12 0.2 Revidering av struktur 2014-02-28 0.3 Marcus Sjölander Införande av information 2014-09-10 0.3.1 Marcus Sjölander Införande och editering av information. 2014-10-01 0.3.2 Marcus Sjölander Införande och editering av information. 2014-10-03 0.3.3 Olof Mårtensson Viss Strukturell redigering, enstaka text redigering 2014-10-06 0.9 Olof Mårtensson Lyft versionsnummer, enstaka struktur redigering 2014-11-10 0.91 Olof Mårtensson Lyft dokumentstatus 2015-01-12 0.92 Olof Mårtensson Enstaka struktur redigering
eklient standard Sessionshantering 2 av 14 Innehåll Historik... 1 Dokumentinformation... 4 Syfte... 4 Målgrupper... 4 Revision... 4 Styrande principer... 4 Hög tillgänglighet... 4 God användarupplevelse... 5 Hög säkerhet... 5 Skalbar/flexibel... 5 Standardiserad... 5 Referenser... 5 Summering... 6 Termer och begrepp... 6 Avgränsningar... 7 Beskrivning... 7 Principskiss... 8 Roller... 8 Generellt... 8 Connection Broker... 9 Web Services... 9 Virtual Desktop Infrastructure... 9 Desktop Deployment Solution... 9 Client Device (klientenhet)... 10 Införande... 11 Generellt... 11 Analys... 11 Användare... 11 Klientenheter... 11 Applikationsegenskaper... 12 Applikationstester och installation... 12 Applikationsåtkomst... 12 Licensiering... 13
eklient standard Sessionshantering 3 av 14 Databaser... 13 Design... 13 Bygg och testa... 14 Införande... 14
eklient standard Sessionshantering 4 av 14 Dokumentinformation Syfte Detta dokument agerar referensdokument och tillhör dokumenttypen standards inom eklient. En standard definierar ett gemensamt språk mellan aktörer och underlättar det dagliga livet för intressenter. Dokumentet definierar egenskaper, krav och instruktioner som behövs i dialog mellan landsting/regioner, med driftspartners/driftsorganisation och med applikationsleverantörer. Man kan vara övertygad om att man i en samling pratar om samma sak - men så behöver det inte uppfattas av alla! En standard visar på vad man kan förvänta sig, båda styrkor och svagheter samt accepteras av inblandade. Informationen som presenteras skall ses som riktlinjer att förhålla sig till. Ett införande av ett sessionsbaserat arbetssätt kräver ingående analyser av befintlig infrastruktur och hänsyn måste tas till specifika behov och önskemål. Målgrupper Intressenter och medlemsorganisationer i eklient Aktörer på marknaden med intresse att följa eklient Partners till medlemsorganisationer i eklient Applikationsleverantörer och produktägare till medlemsorganisationer i eklient Revision Detta dokument revideras årligen. Senaste revidering 2015-01-12. Styrande principer I arbetet med att implementera ett sessionsbaserat arbetssätt bör följande punkter ses som styrande: Hög tillgänglighet Den klart viktigaste principen är att miljön alltid ska gå att nå även fast haverier på enskilda komponenter har inträffat. Målsättningen skall därför vara att bygga bort alla single point of failures. Lastbalansering av tjänster bör vara en genomgående målsättning. I praktiken innebär det en lösning som spänner över fler serverhallar med minst en delkomponent i varje hall. Ett haveri kan det påverka tillgängligheten för en hel serverhall och därmed ha en stor påverkan på den totala tillgängligheten, funktionaliteten och i viss mån antalet användare som kan ansluta. Beroende på hur kravbilden ser ut för respektive lösning bör beslut tas kring hur stor påverkan ett haveri kan tillåtas ha på den totala lösningen. Om en serverhall blir otillgänglig, hur många användare ska den kvarvarande kunna hantera? Räcker det att 50 % av användarna har tillgång till sin arbetsyta under ett eventuellt haveri?
eklient standard Sessionshantering 5 av 14 Viktigt är att SLA:er (Service Level Agreement) finns definierade för varje delkomponent som har påverkan på den totala tillgängligheten. Här ingår också delar som indirekt påverkar lösningen så som lagring, nätverk, och strömförsörjning. God användarupplevelse Sessionen är användarens arbetsverktyg och ska designas för effektivitet och användarvänlighet. Enkelhet är att föredra då komplexitet ofta försvårar hanteringen av miljön både för användare och supportpersonal. Den del som får i särklass mest uppmärksamhet vid sessionsbaserat arbete är inloggningstider. Här är det viktigt att vara medveten om att vi använder e-tjänstekort för autentisering, inte användarnamn och lösenord. All jämförelse ska ske mot ett arbetssätt baserat på lokal inloggning till en lokal pc. Faktum kvarstår dock, att det är ofrånkomligt att autentisering kommer ta tid både vid etablering av session och vid återanslutning av session. Rimliga mål för inloggningstider bör sättas. Hög säkerhet Ett sessionsbaserat arbetssätt ökar säkerheten ytterligare då inget material lämnar serverhallen. För att logga in krävs ett giltigt e-tjänstekort och all kommunikation mellan delkomponenterna säkras med SSL-certifikat. Kraven på e-tjänstekort gör också att korten i sig innebär en singel point of failure. Utan kort kan användare inte logga in. Hur ska borttappade eller glömda kort hanteras? Skalbar/flexibel Lösningen ska kunna växa eller krympa efter behov. Det kan finnas tillfällen då behovet av fler servrar eller klienter ökar. Ledtiden för att tillgodose behovet skall hållas till ett minimum. En viktig parameter i arbetet är att undvika manuell hantering av de delar som hanterar användarsessioner. Väl fungerande tekniker finns för att sköta detta och dessa bör användas. Exempel på tekniker för hantering av dynamiska lösningar är Citrix MCS och Citrix PVS. Standardiserad En viktig faktor, som egentligen går att applicera på all typ av IT-verksamhet, är att lösningen ska bygga på vedertagna och välkända produkter på marknaden. Det är framförallt viktigt ur ett supportperspektiv när behov av hjälp uppstår. Att bygga en proprietär lösning fungerar oftast bra så länge som adekvat kompetens finns att tillgå. Referenser Ex närliggande standarddokument i eklient referenser till direkta fakta eller ställningstaganden i standarden RefID DokumentNamn Sökväg 1 eklient standard Klassificering av klienter http://www.inera.se/tjanster-- PROJEKT/eKlient-i-samverkan/Gemensammastandarder/ 2
eklient standard Sessionshantering 6 av 14 Summering Sessionshantering ses ofta som en nyckel till en högre användarupplevelse i en miljö där användare rör sig mellan flera enheter. Denna standard beskriver de delar som ingår i den infrastruktur som krävs för att en fungerande sessionshantering skall uppnås. Beskrivningen av standarden i detta dokument tar upp några exempel på produkter som uppfyller de styrande principerna. Det står dock varje kund fritt att välja de produkter som bäst motsvarar respektive gällande krav på funktionalitet. I de fall det namnges produkter gäller det exempel på produkter med jämförbar funktionalitet. Teknikerna MCS och PVS nämns under rubriken termer. De är tjänster som ingår i Citrixbaserade lösningar och används som exempel på hur en dynamisk infrastruktur kan användas. För mer information, se mer under rubriken Termer och begrepp. Termer och begrepp Nedanstående termer och begrepp förekommer i beskrivningen av sessionshantering. Begrepp/term Beskrivning T1 E-tjänstekort avser landstingsstandarden SITHS T2 Session beskriver en användares virtuella arbetsyta. En session kan vara någon av följande varianter (T2.1 T2.3): T2.1 Publicerad applikation användaren skapar en session mot en enskild applikation. Applikationen exekveras centralt i ett klient- eller serveroperativsystem. T2.2 Server Desktop session baserad på ett serveroperativ. Användaren delar tillgängliga hårdvaruresurser, så som minne, processor och lagring, med andra användare anslutna till servern. T2.3 Client Desktop session baserad på ett klientoperativsystem. Användaren har exklusiv åtkomst till klientens tilldelade hårdvara. Relativt dyr i förhållande till de andra sessionsbaserade alternativen då lösningen kräver mer hårdvara. T3 Mobilitet termen mobilitet kommer här att syfta till interna användares möjlighet att byta klientenhet och flytta med sig sin arbetsyta. T4 CRL Certificate Revocation List. Enkelt förklarat en lista innehållande giltighetstiden för certifikat. Varje gång en användare loggar in med ett e-tjänstekort kontrolleras detta mot en CRL för verifiering av giltighet. T5 HA term för att ange hög tillgänglighet. (High Availability) T6 Farm term för en logisk grupp av servrar konfigurerade att för att hantera användarsessioner. Farmen kan bestå av både server och klientoperativsystem. T7 Silo / worker group term för gruppering av maskiner inom en farm. Alla maskiner i samma silo eller worker group bör ha samma konfigurering och uppsättning applikationer. T8 MCS Machine Creation Services. En funktion från Citrix som bygger på virtuella mallar.
eklient standard Sessionshantering 7 av 14 T9 PVS Provisioning Services. En funktion från Citrix som bygger på streaming av image filer. T10 VDI Virtual Desktop Infrastructure. Termen VDI (Virtual Desktop Infrastructure) syftar till att användare når en desktop, klient eller serverbaserad, i ett virtuellt lager. Skillnaden mellan klient och serverbaserad VDI är: Klient en enskild användare åt gången kan vara ansluten till arbetsytan. Lösningen Kräver mer av hårdvaran och har relativt låg användardensitet. Server flera användare delar resurserna tilldelade till arbetsytan. I vardagstal syftar termen VDI på ett virtuellt klientoperativsystem, t.ex. Windows 7 eller Windows 8 Avgränsningar I sin nuvarande form behandlas inte sessionshantering för externt ansluta användare i dokumentet. Klientenheter är i dokumentet avgränsat från att omfatta mobila enheter. Vi tar inte parti för några produkter eller produktleverantörer i dokumentet utan har endast använt deras vokabulär och begrepp. Beskrivning Med sessionshantering menas att en arbetsyta (applikation, desktop eller en kombination av dessa) pausas i det skick användaren lämnar den för att sedan återta arbetsytan på samma klient, en annan klient eller annan typ av enhet. Initialt syftar standarden till att adressera sessionshantering internt mellan olika klienter av typen pc. Med termen arbetsyta menas den miljö användaren arbetar i, t.ex. ett klientskrivbord, ett delat serverskrivbord eller en applikation. En förutsättning för att sessionshantering överhuvudtaget ska fungera är att vi har en session att hantera. Syftet med ett sessionsbaserat arbetssätt är att en användares påbörjade arbete pausas och att detta flyttas med användaren medan denne byter klientenhet under dagens lopp. I en traditionell klient-serverlösning loggar användaren in på en dator och startar ett antal applikationer. När användaren behöver flytta sig till en annan lokal, våning eller avdelning måste allt arbete avslutas och användaren ska logga ur. För att återuppta arbetet igen måste en ny inloggning genomföras och samtliga applikationer som används startas på nytt. I ett sessionsbaserat arbetssätt används klienter mer som en plattform för att koppla sig mot en centralt placerad arbetsyta. Arbetsytan kan vara olika beroende på användarens behov t.ex. publicerad applikation, publicerat serverskrivbord eller publicerat klientskrivbord. Oavsett typ av arbetsyta så hanteras sessionen centralt. Arbetsytan startas vanligtvis i virtuella servrar eller klienter och pausas när användaren byter klient. Vilken typ av arbetsyta som passar användarna bäst går inte att generellt säga. Utredning om t.ex. applikationsberoenden, behov av kringutrustning, antalet applikationer och support kan ge en fingervisning om vilken typ som passar bäst. Oavsett typ skapas och hanteras sessioner enligt samma principer:
eklient standard Sessionshantering 8 av 14 Användaren loggar in på en klient. Efter godkänd autentisering/auktorisering initieras session mot för användaren tillgängliga resurser (applikation, serverskrivbord eller klientskrivbord). Initieringen innebär att användarens SITHS-kort kontrolleras mot gällande CRL och antalet gånger kontroller sker mot CRL är olika beroende på hur infrastrukturen satts upp. Session etableras på någon tillgänglig server/virtuell klient. Var sessionen etableras beror på vilken typ av arbetsyta användaren har startat. Efter att en initiering och etablering har skett har användaren tillgång till en egen arbetsyta som centralt kan hanteras. När behovet av att byta klient uppstår drar användaren ur sitt e-tjänstekort ur kortläsaren varvid sessionen pausas och försvinner från klienten. Sessionen lever dock kvar i den centrala miljön och kan återupptas från annan klient. Principskiss Roller Generellt Lösningen beskriven i principskissen bygger på ett antal servrar med olika roller. I en lösning designad för hög tillgänglighet ska alla roller och funktioner tas i beaktning. Rekommendationen är att använda sig av lastdelning med t.ex. F5 eller Citrix NetScaler. Oavsett vilken typ av produkt som används för lastdelning ska dessa vara konfigurerade att ingå i ett HA-par för att optimal tillgänglighet ska uppnås.
eklient standard Sessionshantering 9 av 14 Connection Broker Server med tjänster för att hitta den för tillfället mest lämpliga server eller klient att etablera ny session på. För att säkra god tillgänglighet bör ett minst två dedikerade Connection Brokers konfigureras. För att ytterligare säkra upp tillgängligheten kan Connection Broker-tjänsten lastbalanseras med hjälp av lastbalanserare. Web Services Rubriken Web Services får representera tjänsten till vilken klienten kopplar sig för att få tillgängliga arbetsytor. Det kan handla om server desktop, klient desktop eller publicerade applikationer. Web Services har kontakt med Connection Broker, som i sin tur förmedlar information från farmen tillbaka till Web Services för att slutligen skickas till klienten. Web Services kan med fördel lastbalanseras med hjälp av Citrix NetScaler. Lastbalanseringen i NetScaler använder inbyggd intelligens och kontrollerar tillgängligheten genom att kontakta de tjänster som är kritiska. Virtual Desktop Infrastructure Termen får representera den grupp av servrar och klienter som är konfigurerade för att hantera användarsessioner. För att en optimal användarupplevelse ska uppnås är det viktigt att dessa maskiner hanteras på ett sätt så alla specifika typer av maskiner är identiska. Det kan finnas behov av olikhet gällande konfigurering av t.ex. lokalt installerade applikationer eller andra systemberoenden, och då grupperas dessa maskiner i silos eller worker groups och hanteras enhetligt. Anledningen till att servrar och klienter som ska hantera användarsessioner är identiska är att användarna inte själva väljer var en session ska etableras. Om det skiljer sig i konfiguration mellan två maskiner i samma worker group kan det resultera i att dessa beter sig olika för användaren. Funktioner (och applikationer, systemberoenden, ODBC-kopplingar etc) som ena dagen fanns för användaren helt plötsligt är borta. Dessa maskiner bör också kunna skalas efter ökat eller minskat behov. Det kan finnas perioder under ett kvartal eller år då behovet av mer maskiner ökar under en kort period och då ska det gå snabbt och enkelt att justera miljön efter det ändrade behovet. Det finns ett flertal fösningar för att hantera identiska servar och några exempel på dessa är Microsoft SCCM, Citrix MCS och Citrix PVS. Desktop Deployment Solution Med termen Desktop Deployment Soution menas sättet på vilket servrar och/eller klienter installeras. Målet bör vara att automatisera installationerna så långt som möjligt med syfte att eliminera manuella fel. Ett vanligt exempel på en Client Deployment Solution är Microsoft SCCM. Funktionen hos SCCM är att utan handpåläggning installera klienter som har certifierats in i den aktuella IT-miljön. Att certifiera en klient handlar t.ex. om att paketera drivrutiner och annat modellspecifikt som kommer behövas i samband med installationerna. Installationerna som utförs är fullvärdiga installationer där klientens operativsystem och all annan tillhörande mjukvara installeras. Alla steg som tidigare gjordes manuellt har automatiserats.
eklient standard Sessionshantering 10 av 14 Ett annat exempel på en Desktop Deployment Solution är Citrix Provisioning Services, även kallat Citrix PVS. Även fast Citrix PVS kan klassas som en Deployment Solution skiljer det sig en hel del från Microsoft SCCM. I Citrix PVS hanteras så kallade images, avbilder av en klients hårddisk, och dessa strömmas ut vid start av datorn. Citrix PVS kan användas för att strömma ut avbilder till fysisk hårdvara men används med marginal oftast till att strömma ut till virtuella servrar och klienter. Imagen som används av PVS måste även den installeras på något sätt och därför kompletterar Microsoft SCCM och Citrix PVS varandra bra. Exempel: I ett scenario där VDI ska användas för att tillgängliggöra en klientbaserad desktop till användaren fungerar t.ex. Microsoft SCCM ypperligt till att installera operativsystemet och eventuella basapplikationer. Dock har SCCM svårt att skala upp och ner lösningen på ett snabbt och effektivt sätt och där kan Citrix PVS/MCS lösa uppgiften. Låter vi Microsoft SCCM hantera klientinstallationen och Citrix PVS/MCS sköta hanteringen har vi en lösning där minimal mängd handpåläggning behövs. Client Device (klientenhet) Även om möjligheten och tekniken finns att använda enheter så som läsplattor och mobiltelefoner menas här termen Client Device (klientenhet) en stationär eller bärbar dator i någon form. En infrastruktur som anpassas för att hantera mobiltelefoner och plattor, t.ex. ipads, kräver en del bakomliggande system som i sig inte har med ett sessionsbaserat arbetssätt att göra. Det kan t.ex. handla om MDM-lösning för hantering av enheter då man vill säkerställa att material inte finns tillgängligt utanför det interna nätverket. Användning av trådlösa enheter kräver också ett väl utbyggt trådlöst nätverk. Mobila enheter hanteras inte som en standardiserad enhet och faller därför utanför ramarna för detta dokument.
eklient standard Sessionshantering 11 av 14 Införande Generellt Arbetet med att införa ett sessionsbaserat arbetssätt är omfattande och tidskrävande då det ställer höga krav på infrastrukturen. Allt som sker och processas i underliggande lager påverkar användaren och dennes upplevelse. Det är därför av största vikt att samtliga delar tas i beaktning och optimeras för bästa prestanda[se bild t höger]. Man kan säga att användarupplevelsen är summan av den samlade miljön. Ett vedertaget och strukturerat arbetssätt vid införande av sessionsbaserat arbetssätt ska användas. Generellt sett innefattar det följande steg: Analys Design Bygg och testa Införande Analys Samtliga delar av infrastrukturen analyseras genom att granska de tekniska lösningarna i detalj men även genom intervjuer med ansvarig personal. Granskningen och intervjuerna ska genomföras av personer med erfarenhet av liknande uppdrag och god kunskap om kraven på ett sessionsbaserat arbetssätt. Erfarenheten visar att ett arbete av den här typen lätt uppfattas som kritik mot den interna IT-personalen och det är därför av största vikt att information om pågående arbete kommuniceras med stor tydlighet. Målet med intervjuerna är att fånga upp alla styrkor och eventuella svagheter, inte att nervärdera befintliga arbetsinsatser. Inom ramarna för analysen gås ett stort antal områden igenom för att bedöma hur redo befintlig itinfrastruktur och organisation är. Vissa delar kan avhandlas relativt snabbt medan andra kan behöva mer tid beroende på komplexitet och antalet personer som måste tillfrågas. Nedanstående lista visar exempel på områden som granskas och frågor som behöver utredas under analysen. Användare Hur många kommer använda lösningen på daglig basis? Behöver vi ta hänsyn till användare som ansluter externt ifrån? Finns det speciella krav eller behov för vissa typer av användargrupper? Hur ser användarbeteendet ut gällande inloggningar vid olika tider på dygnet? Naturligtvis kommer frågorna få olika svar beroende på vem i verksamheten man frågar. Viktigt är att personerna som tillfrågas har god insyn i gällande arbetssätt och även skillnader på olika avdelningar och grupper. Klientenheter Här granskas den befintliga klientplattformen men även kommande plattform för att undvika fallgropen med att bygga in sig i beroenden som är svårt att komma ifrån.
eklient standard Sessionshantering 12 av 14 Vilken hårdvara används? Finns support och garantiavtal? Vilket operativsystem används? Finns det särskilda krav på vissa säkerhetsuppdateringar och service packs? Finns det planer på en framtida klientplattform som det måste tas hänsyn till? Finns det eventuella investeringsbehov? Applikationsegenskaper Vilka är de viktigaste verksamhetsapplikationerna att ta hänsyn till? Vem är ansvarig förvaltare för varje respektive applikation? Finns det särskilda krav och beroenden? Klarar applikationerna övergången till Windows 7/8, Windows 2012, Windows X? Exempel på applikation att ta hänsyn till är så kallade Click-Once applikationer. Det är applikationer som har en inbyggd funktion för att uppdatera applikationen automatiskt vid start. Problemet vi ställs inför är en applikation som används av fler personer samtidigt och som helt plötsligt kan uppdatera viktiga programfiler. Resultatet vid ett sådant scenario blir att alla tidigare anslutna användare får ett avbrott i arbetet och i värsta fall går miste om data. I de fall där Click-Once applikationer inte kan undvikas bör detta tas hänsyn till vid designen av miljön. Det kan t.ex. handla om att installera upp ytterligare filkluster för lagring av personliga applikationskataloger för att undvika konflikter vid uppdatering av applikationen. Applikationstester och installation I en sessionsbaserad miljö bör strävan vara att särskilja hårdvara från operativsystem och operativsystem från applikationer. Vi vill på ett dynamiskt sätt kunna byta applikationer utan att behöva installera om operativsystemet. Rekommenderat är att paketera applikationerna i största möjligaste mån med App-V-teknik. Normalt sätt paketeras applikationer för att installeras men med Microsoft App-V paketeras applikationer för att exekveras (startas). En applikation som är paketerad med App-V kan göras plattformsoberoende och samma paket kan användas på både servrar och klienter. Istället för att installera applikationerna strömmas dessa ut vid programstart och endast den del av applikationen som behövs för att starta skickas till klienten. Under användning av applikationen strömmas bit för bit ut vartefter användaren aktiverar och använder fler funktioner. Alla filer som tillhör applikationen är samlade i en virtuell area lokalt på klienten. Det medför att vid ett eventuellt haveri av applikationen kan denna area, eller cache, raderas och applikationen kan strömmas ut på nytt. Hur testas applikationerna? Hur paketeras applikationerna? Vem ansvarar för att en applikation blir godkänd att exekveras i produktionsmiljö? Finns det tillgängliga supportavalt för varje verksamhetskritisk applikation? Applikationsåtkomst Den här punkten behandlas om det finns en befintlig sessionsbaserad lösning på plats. Går det att återanvända någonting av befintlig lösning? Vad funkar, vad funkar inte? Hur kommer användarna åt sina applikationer? Hur ser tillgänglig arbetsyta ut, skrivbord eller enskilda applikationer? Går de att nå via en webbportal? Går de att nå utifrån via publika nät (internet)?
eklient standard Sessionshantering 13 av 14 Licensiering Här granskas befintliga licenser och eventuella investeringsbehov. I det fortsatta arbetet kommer punkten med licenser och användare analyseras för att ge ett riktvärde på hur mycket licenser som behövs. Databaser Många av de applikationer som används har en databas för informationshantering. Applikationen kommer aldrig fungera bättre än vad databasen/databasservern kan leverera. Vilken typ av databaser finns i verksamheten? Finns det versionskrav? Räcker nuvarande prestanda eller finns det ett investeringsbehov? Redundans och tillgänglighet? Finns interna SLA:er definierade? Finns adekvat kompetens gällande administration tillgänglig i verksamheten? Samtliga delar av ovanstående punkter måste tas i beaktning för att helheten ska blir en miljö med bra användarupplevelse. Design Om analysen visar på bristfälliga lösningar eller funktioner bör dessa åtgärdas innan arbetet med designen fortsätter. Det finns en stor flora av brister som kan stötas på men till de vanligaste hör följande: Hög latency (fördröjning) i nätverket. I ett sessionsbaserat arbetssätt där användaren och applikationen i vissa fall befinner sig långt ifrån varandra är ett stabilt nätverk med låg fördröjning A och O. Åtgärder kan handla om att uppgradera eventuella långsamma WANlänkar till kliniker eller uppgradera utrustningen i nätverket. Långsam lagring. Här får man ta sig en funderare på vad det är som är målet med lösningen. En lösning som baseras på Microsoft RDS eller Citrix HDX kräver i regel mindre prestanda från en lagringslösning än en VDI-lösning baserad på t.ex. Windows 7/8.1. Om lagringen anses vara allt för undermålig för att passa in i någon av lösningarna bör denna bytas ut helt. Om målet är en VDI-lösning med Windows 7/8.1 bör man undersöka möjligheterna att komplettera med ett SSD-baserat SAN där de virtuella klienterna placeras. Om analysen däremot visar att befintlig infrastruktur klarar att hantera ett sessionsbaserat arbetssätt går arbetet vidare till designfasen. Här kommer önskeblocket fram. Hur ska den nya miljön se ut och upplevas av användarna? Vad ska användarna komma åt? Viss beaktning måste tas till resultatet av analysen då stora delar troligtvis kommer förbli oförändrade. Dock behöver man här definiera vilka grundläggande inställningar och funktioner som ska aktiveras i den kommande miljön. Ju mer detaljer som kan specificeras desto bättre kan miljön designas och så få delar som möjligt lämnas åt slumpen. Varje del ska förankras i den mån det går och når man vissa delar som helt enkelt inte går att besluta om kommer dessa testas och granskas i det kommande arbetet. Under den här delen tittar man på vilka delar som ska användas (se exempelbilden i punkten principskiss). Kommer eventuella webbservrar kunna placeras i separat åtskilda serverhallar för redundans? Om inte, hur ska de placeras och byggas för bästa tänkbara åtkomst och prestanda under gällande förutsättningar?
eklient standard Sessionshantering 14 av 14 Om kraven på tillgänglighet definieras tydligt kan det också behövas beslut kring eventuella nyinvesteringar. Det kanske är läge att ta tag i den där fibern mellan serverrummen som det pratats om i några år, eller en gång för alla bygga ett väl dimensionerat SQL-hotell för att säkra åtkomsten till databaserna samtidigt som man bättre kan utnyttja eventuella licenser. Bygg och testa När analys och designfasen är klara byggs och testas målmiljön för att säkerställa att det som planerats fungerar. Införande En viktig del som kräver god planering. Hur ska användarna migreras till den nya plattformen för minsta möjliga påverkan på den dagliga driften? Hur införandet ska ske är till stor del beroende på vad som beslutats under designfasen. Hur ser lösningen ut? Är det en övergång till ett helt sessionsbaserat arbetssätt eller är det en mix av lokala applikationer tillsammans med applikationer i en RDS eller HDX-session? Målsättningen ska vara att migreringsarbetet har minimal påverkan på verksamheten. Sällan passar ett och samma migreringssätt på alla ställen. Inventera befintliga beroenden, t.ex. externt ansluten utrustning så som skanner och röntgen, i klientmiljön och säkerställ att en handlingsplan finns för alla olika scenarion.