Miközben a Citrix továbbra is azon dolgozik, hogy a Citrix XenDesktop és a FlexCast modell segítségével a felhasználók bárhonnan képesek legyenek végezni munkájukat és együttműködni, a dolgozói tulajdonú mobilkészülékek (BYOD) kezdeményezésének köszönhetően egyre több mobilfelhasználó kerül a képbe. A Citrix XenMobile az okostelefonoktól a táblagépekig nagyszámú mobileszközön támogatja a mobilfelhasználást.
Amikor felhasználókat kívánunk hozzáadni a XenDesktop környezethez, gyakran feltesszük a kérdést: milyen hatása lesz a műveletnek a meglévő környezetre, illetve mi a metszete a XenDesktop és a XenMobile felhasználók halmazainak?
Annál a 30 000 főt foglalkoztató cégnél például, ahol 5 000 felhasználó végzi munkáját távolról, gyakorlatilag minden dolgozó egyszersmind potenciális mobilfelhasználó is. A dolgozók nem mindegyike mobilfelhasználó és távoli munkavégző is egyben, de a két csoport között jelentős átfedés lehet. Telepítés esetén a XenMobile a saját komponenseit használja az XenDesktopon kívüli mobilfelhasználóknak a rendszerbe való bekapcsolására.
Ez a dokumentum a XenMobile (mobil-) felhasználók és a XenDesktop (távoli) felhasználók halmazának metszetére koncentrál, ahol a két felhasználói kör elsődleges metszetét egy NetScaler készülék biztosítja. A mobilfelhasználók esetén a fő problémát a MicroVPN-forgalom, míg a távoli felhasználók esetén az ICA-forgalom jelenti.
Célok
Jelen dokumentum célja, hogy a sikeres üzembe helyezés biztosítása érdekében tervezési útmutatóul szolgáljon azáltal, hogy megvizsgálja, milyen hatást gyakorol a mobilfelhasználók hozzáadása a NetScaler stabil működésére egy meglévő XenDesktop környezeten belül.
A cél annak tisztázása, hogy melyik az a pont, ahol a távoli felhasználói élményre már hatással van a mobilfelhasználók hozzáadása, és ahol a NetScaler készülék megközelíti a határértékeket.
Előfeltevések
A stratégia egészének kialakítása az alábbi előfeltevések mellett történt:
- Már létezik egy XenDesktop 7.x környezet, amikor a távoli felhasználók erőforrásokat érnek el a Citrix NetScaler készüléke(ke)n keresztül.
- A mobilfelhasználókat a már meglévő környezethez adjuk hozzá.
- A XenDesktop környezetet 5 000 távoli felhasználó kezelésére konfigurálták. A felhasználók munkaterhelését egy Login VSI (Virtual Station Interface) fogja generálni.
- A távoli felhasználók által generált munkaterhelést egy Citrix XenMobile fejlesztői csoport által készített segédprogram állítja majd elő, amely felhasználónként több MicroVPN-kapcsolatot hoz létre.
Elméleti architektúra, módszertani tesztelés
Az alábbi diagram az elméleti architektúra részleteit mutatja.
A VMware vSphere 5.1 segítségével 5 000 felhasználóra méretezett XenDesktop 7 tesztkörnyezetben való tesztelés a Validated Design Guide-ban meghatározott elvek szerint történt. Ez a módszer biztosította, hogy az 5 000-es felhasználószám elérése a XenDesktop konfigurációját ne érintse.
A XenDesktop összes felhasználója távoli felhasználóként lett beállítva, míg a XenDesktop munkaterhelés vezérlését a LoginVSI 3.7 végezte. A XenDesktop háttérösszetevői – a StoreFront, a Delivery Controller, illetve a Provisioning Services – a Validated Design Guide-ban leírt hardver és konfiguráció szem előtt tartásával úgy voltak beállítva, hogy kezelni tudják az 5 000 felhasználó munkaterhelését. A StoreFront és az App Controller nem voltak a rendszerbe integrálva.
A mobilfelhasználók tesztelésére egy belső fejlesztésű Citrix tesztsegédprogram szolgált, amely kapcsolatot hoz létre a NetScaler készüléken keresztül egy adatközponti elhelyezésű echo-szerverrel. A segédprogram az echo-szerver segítségével két MicroVPN kapcsolatot épít fel a mobilfelhasználók és az adatközpont között, amivel a NetScaler által létrehozott két MicroVPN-t szimulálja, amelyek a mobilfelhasználó bejelentkezésekor, valamint a kapcsolat alatt jönnek létre.
A beállított felhasználók 50-50 százalékban használtak iOS és Android készülékeket.
A tesztek során először a LoginVSI-t indítottuk el, amely az 5 000 távoli felhasználó munkaterhelését vezérelte. Miután az 5 000 felhasználó bejelentkezett és sikeresen elindította a munkameneteit, egy 30 perces nyugodt időszak következett, hogy a rendszer stabil működése biztosított legyen. A 30 perces nyugodt időszak után elindítottuk a Citrix XenMobile tesztelési segédprogramot. A segédprogram három terhelésgenerátort futtatott, amelyek mindegyike egy-egy kijelölt App Controller echo-szerverrel kommunikált a háttérben. Mindegyik terhelésgenerátor úgy volt beállítva, hogy 5 000 mobilfelhasználót hozzon létre; az egyes terhelésgenerátorokat 10 perces különbséggel indítottuk el.
Mindegyik terhelésgenerátor óránként 833 bejelentkező mobilfelhasználót szimulált, akik a teszt hátralevő idejére bejelentkezve maradtak. A három terhelésgenerátor egyidejű futása mellett a bejelentkezési terhelés óránként 2 499 mobilfelhasználó volt. A korábbi tesztek tanulsága az volt, hogy az ennél magasabb szimulált bejelentkezési szám hibákat okozott a háttérben futó echo-szerveren, amely nem volt képes lépést tartani a terheléssel. Meg kell jegyezni, hogy a XenMobile-ban a méretezhető, redundáns konfiguráció érdekében az App Controllerek fürtözött, illetve feladatátvételi üzemmódokra is beállíthatók. Jelen tesztkörnyezetünkben azonban egy alkalmazásindító az adatközpontban csak egy App Controllerhez volt konfigurálva az elindítási folyamatok hatékonyabb kézben tartása érdekében.
A tesztelési környezet figyelését NetScaler Insighttal végeztük. A NetScaler Insight az AppFlow (AppFlow.org) nyílt szabványú technológiát használja, amely adatfolyamonkénti szintű alkalmazás- és hálózatiadat-kezelést végez. A NetScaler Insight Center volt az ICA-forgalom összegyűjtésének központi kezelője, és ugyancsak e megoldást használtuk az ICA-teljesítmény figyelésére és elemzésére.
A Command Centert használtuk a NetScaler MPX 10 500 készülék CPU- és memóriateljesítményének figyelésére és elemzésére. A NetScaler készülék transzparens módra volt konfigurálva, ami azt jelenti, hogy az ICA-forgalom nem ment át semmilyen VPN-en. A NetScaler Insightot ugyancsak transzparens üzemmódra konfiguráltuk, és egy AppFlow irányelvet állítottunk be az ICA-forgalom összegyűjtésére.
A NetScaler készülék úgy volt konfigurálva, hogy a távoli és a mobilfelhasználókat egyaránt támogassa. Az alkalmazott konfigurációs beállítások a „B“ függelékben találhatók. Tanúsítványalapú hitelesítést nem állítottunk be.
Teszteredmények
A NetScaler Insight által gyűjtött egyik adat a felhasználók ICA-munkameneteinek Round Trip Time (RTT) adatai voltak. Ezt az értéket a NetScaler CPU- és memóriahasználatával együtt megmértük a „nyugodt” időszakban, így kaptunk egy viszonyítási alapértéket 5000 felhasználóra. Az alábbi diagram az ICA RTT pillanatnyi értékét mutatja 5000 felhasználó esetén a tesztkliensek elindítása előtt.
Ezen a ponton az ICA RTT átlagosan 144 ms volt; ezt tekintettük alapértéknek. A 30 perces „nyugodt“ időszak végén elindítottuk a Citrix XenMobile tesztelési segédprogramot. Az alábbi diagramon a CPU-használat látható a teszt elindítása után. Érdemes figyelembe venni, hogy az ICA RTT diagram és a CPU-használati diagram között egy óra telt el.
13.20-kor a CPU-használati diagram az ICA RTT diagramhoz hasonló értéket mutatott, amiből az látszik, hogy az 5000 távoli felhasználó a NetScaler készülék CPU-teljesítményének átlagosan a 60%-át, memóriájának pedig a 20%-át használta. A mobilhasználati terhelés növekedésével a CPU-használat megközelítette a 100%-ot, míg a memóriahasználat beállt 30%-os szintre.
Az alábbi táblázat a különböző mobilfelhasználói munkaterheléseket és azok hatásait mutatja (ICA RTT / CPU-használat).
Mobilfelhasználók száma | Megszakadt kapcsolat | ICA RTT | CPU % | Memória % |
0 (viszonyítási alapérték) | 144 | 50 | 20 | |
833 | 120 | 65 | 25 | |
1666 | 102 | 80 | 30 | |
2499 | 120 | 80 | 30 | |
3332 | 155 | 80 | 30 | |
4165 | 166 | 85 | 30 | |
5831 | 166 | 85 | 30 | |
6664 | 128 | 85 | 30 | |
7497 | 128 | 85 | 30 | |
8330 | 3 | 189 | 85 | 30 |
9163 | 4 | 123 | 85 | 30 |
9996 | 1 | 151 | 85 | 30 |
10829 | 146 | 90 | 30 | |
11662 | 1 | 155 | 95 | 30 |
12495 | 1 | 119 | 95 | 30 |
13328 | 14 | 191 | 95 | 30 |
A CPU-értékek becsült átlagok az ICA RTT pillanatfelvétel időpontjában. A teszt során nem használtuk a NetScaler javasolt eljárásait a terheléselosztásra, ugyanis az hatással lett volna a CPU-használatra. A vizsgálatok azt mutatták, hogy a CPU-használatból mintegy 15%-ot tettek ki az AppFlow irányelvek, amelyek a NetScaler készülék figyelését és menedzselését végezték.
A táblázaton látható, hogy 3332-es felhasználószámnál anomália lépett fel, mivel az ICA RTT idők 23%-kal megugrottak. Ugyanakkor egyetlen távoli felhasználó kapcsolata sem szakadt meg, és a távoli felhasználói élmény sem romlott. 8330 mobilfelhasználónál az ICA RTT értékek 32%-kal megugrottak, és a távoli felhasználók közül egyre többnek megszakadt a kapcsolata.
Az első jelentős inflexiós pontot a leszakadt felhasználók jelzik, amikor a mobilfelhasználók száma eléri a 7 500 főt, akik közül 5 000 távoli felhasználó.
Méretezés
A tesztelés következő fázisában annak megállapítása volt a cél, hogy a távoli felhasználók számának megváltoztatása jár-e nagyságrendi változásokkal. Ugyanezt a tesztkonfigurációt használva megismételtük a teszteket 3 000 és 4 000 távoli felhasználóval is, hogy lássuk, felfedezhető-e valamilyen tendencia. A következő diagram a CPU- és memóriahasználatot mutatja 3 000 felhasználóval futtatott, viszonyítási alapértékeket mutató teszt esetén, a teszt kezdetét követően.
Az ICA RTT viszonyítási alapértékét, 36 ms-ot, 10.40-kor mértük. A CPU-használat ekkor valamivel 20% fölött, a memóriahasználat pedig 10% körül volt. Amint a mobilfelhasználók számát 14000-re növeltük, a CPU-használat elérte a 85%-ot, amint az az alábbi diagramon is látszik:
Amint a mobilfelhasználók száma nőtt, majd meghaladta a 14 000-et, a NetScaler válaszideje mind a NetScaler Insight Center, mind a Command Center felé megnőtt. A teszt befejezése után a naplófájlok vizsgálata azt mutatta, hogy 14 000 mobilfelhasználó mellett az ICA RTT értékek a 35–45 ms tartományban maradtak, de a NetScaler készülék elérte kapacitása határait.
Amikor a távoli felhasználók számát 4 000-re növeltük, az átlagos ICA RTT idők közepes, 50 ms-os érték körülire nőttek, a CPU-használat pedig ugyancsak kissé megnőtt 35-40% körüli szintre, mielőtt a mobilfelhasználók elkezdtek bejelentkezni.
A CPU-használat végig lineáris emelkedést mutatott, ahogy a felhasználók száma 3000-ről 5000-re nőtt. Amint az a következő diagramon is látszik, 4000 felhasználónál, kb. 11000–12000 bejelentkezett mobilfelhasználó mellett, a CPU-használat nagyon stabilan beállt 85% körüli értékre.
A teszt nagy részében a CPU-használat nagyon stabilan 80% körül volt, de 14000 mobilfelhasználó után a kapcsolódási idő elkezdett növekedni, és az átlagos CPU-használat megközelítette a 90%-ot.
A memóriahasználat mindegyik esetben kb. 30–35%-ig növekedett, és stabilan azon az értéken maradt.
Következtetések
Az alábbi táblázat a mobilfelhasználók számának ajánlott értékeit mutatja.
Távoli felhasználók | Mobilfelhasználók | MicroVPN-kapcsolatok |
50–50% IOS és Andriod | ||
5,000 | 7,500 | 15,000 |
4,000 | 11,000 | 22,000 |
3,000 | 14,000 | 28,000 |
Egy mobilfelhasználó sikeres kapcsolódása esetén két MicroVPN kapcsolat jön létre a NetScaler készüléken keresztül. Arról sem szabad megfeledkeznünk, hogy minden egyes XenMobile alkalmazás, pl.a WorxMail vagy a WorxWeb is több MicroVPN kapcsolatot hoz létre. A Citrix XenMobile tesztsegédprogram miden kapcsolódó felhasználóhoz két MicroVPN-kapcsolatot hozott létre, és ezek fennmaradtak egészen a teszt végéig. Ha a mobilfelhasználók számát átszámítjuk MicroVPN-kapcsolatokra, az 5 000 felhasználós teszt esetében ez 15 000 MicroVPN-kapcsolatot jelent.
A mobilfelhasználók számához a MicroVPN-ek számát is figyelembe kell venni, mert minden egyes XenMobile alkalmazás is egy MicroVPN-t hoz létre. Az ajánlott felhasználószámot nem 100%-os CPU-használatra érdemes megadni, hanem a 85%-os átlagértékre, amikor még egyetlen távoli felhasználó kapcsolata sem szakadt meg.
Az 5 000 felhasználós tesztnél a távoli felhasználók 8 330 mobilfelhasználós terhelésnél kezdtek leszakadni. A méretezési trend azt mutatja, hogy ha 1 000-rel csökkentjük a távoli felhasználók számát, az kb. 3 000-rel növeli a mobilfelhasználók számát, vagy 6 000-rel a MicroVPN-kapcsolatok számát.
A számok extrapolációjával azt kapjuk, hogy nulla távoli felhasználó esetén az MPX 10 500 készülék nagyjából 23 000 mobilfelhasználót (46 000 MicroVPN-kapcsolatot) tud kezelni a NetScaler készülék 90%-os leterheltsége mellett. Ez igencsak összhangban van a Citrix XenMobile csoport által végzett teszt eredményével, amelyben egy hasonlóan konfigurált MPX 10 500 NetScalert használtak.
Összefoglalás
Jelen dokumentum célja végeredményben annak megvilágítása volt, hogy milyen hatást gyakorolnak a mobilfelhasználók a meglévő távoli felhasználókra a két felhasználóhalmaz metszetében, a NetScaler készülékben.
A tesztelés során a NetScaler készülék figyelését NetScaler Insight Centerrel végeztük, amely remek eszköznek bizonyult erre a célra, de nem szabad elfelejtenünk, hogy beállítástól függően befolyásolhatja a NetScaler készülék teljesítményét.
A távoli hozzáférés és a hálózati munka igen összetett környezetet jelentenek, amelyben sok különféle területet kell egymáshoz állítani és összehangolni. Tesztünk során az alapértelmezett beállításokat használtuk, és nem végeztünk semmilyen összehangolást. Minden olyan összehangolási tevékenység, amely hatással van a CPU-használatra, szinte biztosan hatással van a mobilfelhasználókra is.
A teszt célja annak vizsgálata volt, hogy milyen hatással jár a mobilfelhasználóknak a meglévő XenDesktop környezethez való hozzáadása, valamint értékelni szerettük volna a NetScaler teljesítményét is.
A tesztet teljes egészében egy 8 processzormagos, 2,8 MHz sebességű NetScaler MPX 10500 készülékkel végeztük. Az újabb NetScaler készülékek nagyobb teljesítménnyel és magasabb kapacitásértékekkel rendelkeznek, de a méretezési számok így is segítséget nyújtanak annak meghatározásában, hogy mivel érdemes elkezdeni a mobilfelhasználók bekonfigurálását a meglévő XenDesktop környezetbe.
„A“ függelék: Az AppFlow konfigurálása transzparens üzemmódú adatgyűjtésre
Ez a függelék azt részletezi, milyen parancsokat kell futtatnunk, ha a NetScaler MPX 10500 készüléket transzparens üzemmódú adatgyűjtésre kívánjuk beállítani.
Megjegyzés: A NetScaler Insight Centerben nem lehet transzparens üzemmódot beállítani.
A parancssorban végezzük el az alábbi műveleteket:
- SSH-n keresztül jelentkezzünk be a NetScaler készülékbe.
- Az alábbi paranccsal adjuk meg azokat az ICA-portokat, amelyeken a NetScaler készülék figyeli az ICA-forgalmat:
- set ns param -icaPorts 2598 1494
- Adjuk meg a NetScaler Insight Centert a NetScaler készüléken működő AppFlow adatgyűjtőként az alábbi parancs segítségével:
- add appflow collector <name> -IPAddress <ip_addr>
- Az alábbi paranccsal hozzunk létre egy AppFlow műveletet, és rendeljük hozzá az adatgyűjtőt a művelethez:
- add appflow action <name> -collectors <string> …
add appflow policy pol true act
- Az alábbi paranccsal kössük (bind) az AppFlow irányelvet egy globális bind pointhoz.
- bind appflow global <policyname> <priority> -type <type>
bind appflow global pol 1 -type ICA_REQ_DEFAULT
Megjegyzés: Az ICA-forgalomra való alkalmazáshoz a „type” értéke legyen ICA_REQ_OVERRIDE vagy ICA_REQ_DEFAULT.
- Az AppFlow flowRecordInterval paraméterének értékét az alábbi paranccsal állítsuk 60 mp-re:
- set appflow param -flowRecordInterval 60
- Az alábbi paranccsal mentsük a beállításokat: save ns config
„B” függelék: A NetScaler konfigurációja
A NetScaler jelenlegi konfigurációja
Platform | NSMPX-105008*CPU+2*E1K+16*E1K+8*CVM 1620760000 |
CPU | 2835 MHz |
Szoftver | NetScaler NS10.1: Build 120.1316.e.nc, dátum: 2013. okt. 30., 09:23:13 |
Hálózati kapcsolatok | Három fizikai (menedzsmentkapcsolat, LAN-kapcsolat, valamint WAN-kapcsolat) |
VPN vServer konfiguráció
A NetScaler öt VPN vServerhez lett beállítva
- Sfagee.hp1xd7esx.com ICA-munkamenetekhez. Az ezen a vServeren bejövő munkamenetek egy LB VIP-re (elkülönített virtuális NetScaler) lettek átirányítva, amivel a forgalom terheléselosztása lényegében három StoreFront szerver egyikére való átirányítással valósult meg.
- Acagee.hp1xd7esx.com, Acagee1.hp1xd7esx.com, Acagee2.hp1xd7esx.com, és. Mobilfelhasználókhoz. Az egypontos bejelentkezéseket (SSO) és az alkalmazástallózást mindegyik egy-egy App Controllerre irányította át.