XenApp Farm Design: The 2011 Edition. Wolfgang Zimmer, Senior System Engineer CE Rob Sanders, Product Specialist Desktop Virtualisation EMEA

Transcription

1 XenApp Farm Design: The 2011 Edition Wolfgang Zimmer, Senior System Engineer CE Rob Sanders, Product Specialist Desktop Virtualisation EMEA

2 Agenda Configuration Design Zone Design Network Communication Autonomic Computing Enablers Design Adaptation Based on Growth Updates in Citrix XenApp 6

3 Fundamental Concepts Data Store (DS) Core farm configuration & settings Published apps Load evaluators Citrix administrators Server groups Active Directory User policies Server policies Farm-wide settings Data Collector (DC) Connected sessions Disconnected sessions Load balancing License Server License files Licenses in use Licenses available

4 Data Store Selection Indirect mode no longer available For WAN environments, use database replication Data store access consists primarily of reads; writes are infrequent Avoids high latency reads across the WAN

5 Local Host Cache Farm can operate when the Data Store is unavailable Used for resolutions, enumerations, etc. Cannot change configuration (LHC is not an authoritative source) Users can connect to applications if the LHC is unavailable LHC consistency mechanisms Updates when changes occur in the farm IMA service synchronizes on startup and every 30 minutes

6 Active Directory Domain Group Policy Farm Group Policy Uniform policy management Native AD capabilities (modeling, hierarchy, etc) Multi-farm policies Managed via AppCenter Microsoft Group Policy Editor (GPEdit) Utilizes AD schema the data is not store extended! and IMA to distribute

7 LHC s Directory Change Notification AppCenter Management Console WAN Data Collector Data Collector Data Store 1. Change is made in the AppCenter 2. Member server writes the change to the DS & updates its LHC 3. Member server forwards change to the DC 4. DC waits a few seconds for any other LHC updates to batch messages Data Store Replica 5. DC sends the batched changes to the member servers in its zone and other DCs 6. Other DCs forward the information to all of their member servers

8 Domain Group Policy Group Policy Management Console WAN Data Collector Data Collector Data Store IMA restart 1. Change is made on the GPMC 2. Within 1½ to 2 hours, member servers pull and apply updates 3. Every 3 hours, AD replication occurs between domain controllers 4. Within 1½ to 2 hours, member servers pull and apply updates Data Store For machine policies, IMA restart refreshes them immediately. For user policies, logons and reconnects refresh them immediately (Local Domain Controller only). GPUpdate forces synchronization and policy update.

9 Farm Group Policy AppCenter Management Console WAN Data Collector Data Collector Data Store 1. Change is made in AppCenter 2. Member server writes the policy change to the DS & updates its LHC 3. All servers pull policy information from the DS & updates their LHCs 4. Within 1½ to 2 hours, member servers apply updates via the registry. For machine policies, IMA restart refreshes them immediately. For user policies, logons and reconnects refresh them immediately. GPUpdate forces synchronization and policy update. Data Store

10 Worker Groups Equivalent to application silos Logic groupings of servers based on settings and administrative scope Flexible management App publishing Capacity management Preference & failover

11 Worker Groups App Silo 1 Data Collector Data Collector App Silo 2 Site 1 Site 2 Site 3 Zone 1 Zone 2

12 App Publishing - Before

13 App Publishing - After Office Worker Group

14 Worker Group Preference and Failover U.S. Productivity Worker Group European Productivity Worker Group U.S. Engineering Worker Group U.S. Zone Europe Zone

15 Active Directory Recommendations Configuring Active Directory Integration Use Domain Group Policy when possible Provides most scalable, robust infrastructure Use one OU per worker group Smaller policies allow for incremental updates Customize at the OU level (rather than filter at the worker group level) If Farm GPO is used, ensure you have data store replicas for remote sites For mixed use, policies are applied: Local GPO Farm GPO Domain GPO

16 License Server Each client connection must check out a license If the LS is unavailable, clients take grace licenses Grace period is 30 days Multiple farms can share licenses Sizing License server should not be the bottleneck Supports 170 check-outs per second Monitor the license server with licensing PerfMon counters

17 Zone Design Zones are analogous to Active Directory sites DCs manage data flow between zones Information flows upstream Communication only occurs between DCs Zones can span WANs How many zones? Fewer zones are always better! DCs must replicate changes to all other DCs in the farm Bandwidth consumption is proportional to the number of zones Avoid having more than 5 zones in large environments Scale up zones instead of scaling out Test zones are still zones!

18 Zone Design Multipe Sites? Yes Similar # of servers at each site? Yes High BW Site Links? Yes Less than 5 sites? No No No No Yes Single Zone Single Zone / Multi-Site Hub and Spoke Multi-Zone

19 Design Example of Single Zone Data Collector TCP Port 2512 TCP Port 2512 Subnet x Subnet x Subnet x

20 Zone Design Multipe Sites? Yes Similar # of servers at each site? Yes High BW Site Links? Yes Less than 5 sites? No No No No Yes Single Zone Single Zone / Multi-Site Hub and Spoke Multi-Zone

21 Design Example of Single Zone/Multiple Sites Proposed Munich Zone WAN x 500 x 500 WAN x 30,000 x 30,000 x 30,000 WAN London Zone Let s do the math: ( 30,000 logons in NewYork Zone + 30,000 logons in London Zone logons in Munich Zone) * 0.5KB * 2 zones for replication = 60.5 MB of DC updates New York Zone

22 Design Example of Single Zone/Multiple Sites European Zone Proposed Munich Zone WAN WAN x 30,500 London Zone Let s do the math again: WAN x 30,000 ( 30,500 logons in European Zone + 30,000 logons in New York Zone) * 0.5KB * 1 zone for replication = MB of DC updates New York Zone

23 Zone Design Multipe Sites? Yes Similar # of servers at each site? Yes High BW Site Links? Yes Less than 5 sites? No No No No Yes Single Zone Single Zone / Multi-Site Hub and Spoke Multi-Zone

24 Design Example of Hub and Spoke Regional HQs in Europe and Asia connected via high speed links Regional branches connected to HQ via low bandwidth/unreliable links

25 Zone Design Multipe Sites? Yes Similar # of servers at each site? Yes High BW Site Links? Yes Less than 5 sites? No No No No Yes Single Zone Single Zone / Multi-Site Hub and Spoke Multi-Zone

26 Design Example of Multiple Zones San Francisco Primary datacenter 200 servers T1 WAN New York Backup datacenter for business continuity 150 servers

27 Data Collector Sizing & Performance Memory Memory consumption increases with farm size IMA typically uses 100 MB of RAM in a 1000-server farm CPU A dual processor DC can support servers in its zone CPU usage increases as number of servers in the zone increases number of zones increase number of users launching applications increases On a dual quad core, the DC can process 245 connections/second Avoid using farm-wide app limits in environments with 10,000+ users

28 Data Collector Backup Most Preferred Default Preference WAN Preferred Default Preference Not Preferred Limit the number of "Most Preferred" and "Preferred" servers

29 Separating DCs from Session Hosts Controller role Similar XenApp to XenApp 6 and 6 server earlier Full IMA stack All servers XML Service are identical Every Data Collector server receives functionality all dynamic farm data Every Session server can Host trigger role a farm RDS election Session and Host become only a Zone Data Collector Reduced IMA stack Data No Store XML becomes Service bottleneck No Data Collector functionality

30 Controller & Session-host Roles WAN

31 IMA Thread Pooling Users enumerating & launching apps IMA Events

32 Data Collector Performance & Resiliency Self-Tuning Farm Settings IMA event timeouts IMA and resolution worker threads Zone cache entries, etc. Thread Pool Health Monitoring Election "Black Hole" (a server wins elections but can do nothing else!) Pings sent through worker thread pool

33 Election Thresholds What triggers an election? Presentation Server 3.0 and earlier Presentation Server 4.0 HRP02 XenApp 6 Any single message failure Any single non-resolution message failure Continuous message failures for x seconds: x depends on the role of the message x can be tuned via registry keys x temporarily increases following an election Ensures elections are not forced too frequently Isolates bad servers from causing election storms

34 Monitoring Elections Election problems are difficult to troubleshoot Election Alerting Creates an Event Log message Displays the source of the election Integrates with SMA and/or App Performance Monitoring

35 Election Performance Comparison Election Time "XenApp 5 for Windows 2008" "XenApp 6 for Windows 2008R2" 98% reduction Medium-Size Business 2,000 applications 1,000 users 50 servers 1 zone 34% reduction 91% reduction International Enterprise 500 applications 20,000 users 1,000 servers 10 zones High-Density Enterprise 500 applications 50,000 users 1,000 servers 2 zones International Medium-Size Enterprise Business High International Density Enterprise Enterprise High-Density Enterprise

36 IMA Communication Startup Data Store Data Store Replica Replication KB Read = KB = 2.1 Apps Servers in zone License Server Data Collector Data Collector KB Read = 5.57 Apps Member Server Backup DC Member Server Member Server KB = 1.8 license strings

37 IMA Communication Idle Farm Data Store Data Store Replica Replication LHC = 1.45 KB per 30 minutes IMA Ping=0.2 KB every 10 seconds IMA Ping=0.26 KB every 20 seconds License Server Data Collector Data Collector IMA Ping=0.2 KB every 40 seconds Member Server Backup DC Member Server Member Server LS Heartbeat = 0.45 KB every 5 to 10 minutes

38 IMA Communication User Connection Data Store Data Store Replica Replication 0.5 KB License Server 0.76 KB Data Collector Data Collector 0.4 KB Member Server Backup DC Member Server Member Server

39 IMA Communication New DC Election Data Store Data Store Replica Replication KB = (0.05 * Con) +(0.04 * Discon) +(0.013 * Apps) License Server Data Collector Data Collector KB = (0.06 * Con) + (0.06 * Discon) + (0.06 * Apps * Srv_Zone) Member Server Data Backup Collector DC Member Server Member Server

40 Autonomic Computing Model Virtual Machine deployment and resealing With the new Server Role Manager, prep XenApp for imaging Use Provisioning Server or other virtualization technologies to capture and deploy Active Directory configuration Adding servers to an OU automatically applies machine policy settings Autonomic application publishing Worker groups mimic application silos Worker groups need to correspond to OUs Adding servers to an OU automatically adds them to the worker groups Power & Capacity Management Automatically shutdown and restart servers and VMs based on needed capacity

41 How a server becomes a member of a farm With XenApp 6.0 and earlier 1. Server Configuration Tool (SCT) collects the Server Zone assignment and ODBC Settings from the XenApp Administrator 2. Zone assignment is recorded in the ZoneName registry. ODBC Settings are distributed amongst the registry and a DSN File. 3. SCT tool creates the Data Store if needed. 4. SCT starts IMA Service. If the server is not yet part of a farm, IMA uses Zone Assignment in the registry and ODBC Settings in the DSN File and registry to connect to the Data Store and try to join the farm. 5. After the server has joined the farm, the ZoneName s registry key is only used to determine if the Zone Assignment has changed if in the event the XenApp Server went offline.

42 How a server becomes a member of a farm With XenApp Iron Cove 1. Server Configuration Tool (SCT) collects the Server Zone assignment and ODBC Settings from the XenApp Administrator. 2. Zone assignment is stored in LGPO and ZoneName registry. ODBC Settings are recorded into the DSN File, LGPO and registry. Initial Server Zone assignment, Database Server Name, Database Name and Failover Partner name can now be configured in the GPMC as a policy. 3. SCT tool then creates the Data Store if needed. 4. SCT starts IMA Service. If the XenApp is not yet part of a farm, IMA retrieves the Initial Server Zone from policy and copied it to the ZoneName registry, it also reads Initial Database Server Name and Database Name from the policy and copies them into the DSN File.

43 How a server becomes a member of a farm With XenApp Iron Cove (continued) 5. IMA uses Zone Assignment in the registry and ODBC Settings in the DSN File and registry to connect to the Data Store and try to join the farm. 6. After the server has joined the farm, the ZoneName s registry key is only used to determine if the Zone Assignment has changed if the XenApp Server went offline. The initial data base policy settings will be ignored.

44 Policies

45 Deployment Based on User Growth As # of users grow, two timeframes are important to analyzing farm health: Peak # of users simultaneously connecting into the farm Usually occurs in the morning Peak # of users connected within the farm Usually occurs during the day

46 Deployment Based on User Growth Monitor Published Applications Data Store Data Collector XML Service License Server (SQL or Oracle - Optional) Data Store Configuration Logging DB Criteria Business requirements Fault tolerance, backup recovery, and/or config logging CPU > 85% - 90% Memory > 80% ResolutionWorkItemQueueReadyCount > 0 for extended periods of time WorkItemQueueReadyCount > 0 for extended periods of time

47 Deployment Based on User Growth Published Applications Data Collector XML Service License Server SQL or Oracle Data Collector Data Store XML Service Configuration Logging License DB Server Backup Data Collector XML Service Monitor Business requirements Criteria Fault tolerance, backup recovery, and/or config logging CPU > 85% - 90% Memory > 80% ResolutionWorkItemQueueReadyCount WorkItemQueueReadyCount > 0 for extended periods of time > 0 for extended periods of time

48 Deployment Based on User Growth Published Applications SQL or Oracle Data Collector License Server Backup Data Collector Data Store XML Service XML Service Configuration Logging DB License Server Monitor Criteria CPU > 85% - 90% Memory > 80% ResolutionWorkItemQueueReadyCount > 0 for extended periods of time WorkItemQueueReadyCount > 0 for extended periods of time LastRecordedLicenseCheck-OutResponseTime > 5000 ms

49 Performance Improvements 91% decrease in application resolution time 88% decrease in AppCenter discovery time 82% decrease in printer driver replication time 50% faster installation time 48% faster domain user logon time 17% more users per server

50 In Summary Configuration Design Zone Design Network Communication Autonomic Computing Enablers Design Adaptation Based on Growth Updates in Citrix XenApp 6

51 Feedback und Präsentationen Ihre Meinung ist uns wichtig. Bitte nehmen Sie sich einige Minuten Zeit, unseren Online Feedbackbogen auszufüllen. Den Link dazu erhalten Sie einige Tage nach der Veranstaltung. Im Anschluss an den Fragebogen haben Sie Zugriff auf die Downloadseite der Präsentationen.

52