I got recently a request for AppDNA sizing document and i thought about putting together some considerations regarding how to define the needed resources. This could be used as a guideline for sizing AppDNA environments, but it is not meant to be definitive as resource allocation depends on various elements like virtual machine snapshot configurations, SQL configuration, multitenancy and system utilization rate.
Everything presented here is based on assumption to guarantee resources for all configured workloads under full utilization with recommended system requirements.
|AppDNA Server||Hosts IIS websites|
|AppDNA Clients||Communicates with hypervisor and IIS websites|
|IIS Website||Communicates with client software and SQL database|
|SQL server||Stores AppDNA data|
|Virtual machines||Application capturing, repackaging and sequencing|
AppDNA server with IIS website
AppDNA server and required IIS website is relatively static for the required resources. However, it is clear that additional sites (multitenancy) increases the needed resources. Because AppDNA is backend system for IT organization rather than end-user system, the number of users per site is not critical as it rarely is more than few, even when end users would be accessing the application reports thru webinterface the number of concurrent users can not be considered to exceed the limits for increasing the resources.
IIS site is the communication channel between AppDNA client software and SQL database. Typical IIS requirements would be acceptable, but in case of multitenant environment where multiple sites would be running on single AppDNA server, reasonable amount of resources should be assigned to guarantee flawless operation, 2GB of memory per site should be added on top of single site configuration.
AppDNA clients are responsible for communication between the IIS website running on AppDNA server and the hypervisor hosting the virtual machines used for install capture. AppDNA client software is typically running on workstations of AppDNA users and therefore has no impact for scaling the resources of the server side environment. Because it is possible that the workstation is also hosting the virtual machines used for capturing, repackaging or sequencing, sufficient resources should be guaranteed just like in case of running the virtual machines in datacenter.
SQL server instance is the most critical part of AppDNA environment as most of the processing is reading or writing data on the database. Especially multitenant environments requires extra considerations for scaling the resources as multiple databases would be running on single SQL instance or multiple instances on single SQL server. Key resources for SQL workload are memory, CPU and storage and SQL performance is the biggest single factor for overall AppDNA system performance.
Some of the key considerations for SQL resources starts from setting the maximum memory allocated for the SQL instance as by default SQL consumes all resources it has available. Second consideration is related to assigning minimum memory per query, recommended value is 2GB. Number of simultaneous queries multiplied with minimum memory per query defines the minimum amount of RAM needed for the SQL instance.
For multitenant environments, it is recommended to increase the number of simultaneous queries by two per each additional database. Adding two queries per database allows all databases to operate at the recommended level, but also allows simple resource sharing from unutilized databases for other databases.
Another factor for scaling the SQL resources is CPU, where 4 cores (virtual or physical) is recommended for each SQL instance running AppDNA operations.
Also an important factor for SQL scaling is storage. Refer to Citrix eDocs for correct disk setup. As a rule of thumb, it is recommended to have databases and TempDB running on RAID10 setup. Especially in case of single physical server with local storage, RAID10 would offer better balance between redundancy and performance over RAID5 because parity calculation required by RAID5 can use considerable amount of resources during write action. If databases are running on SAN, the disk setup is usually better than recommended. However, diskspace must be enough for holding all databases and recommendation is to allow unrestricted growth of databases.
As far as i know, Citrix does not have official recommendation regarding clustering, mirroring or load balancing of AppDNA SQL databases. Even though SQL clusters offers mechanism for redundancy it doesn´t mean high availability as transferring the actions from failing node to other may take minutes. Mirroring is much more agile for offering high availability, but has also disadvantages on disaster recovery. Building redundant high availability SQL cluster requires minimum four nodes (Mirrored cluster), which makes the setup more complex and it still would miss load balancing.
Because AppDNA is not system requiring extreme uptimes, regular backups is enough for disaster recovery and clustering can be traded to performance. As an example it means configuring mirroring for high availability and use NetScaler for load balancing the mirroring partners and accelerating SQL performance.
Install capture virtual machines
Virtual machines used for capturing applications, repackaging and sequencing can be configured by recommended resources per used operating system. However, method used for virtual machine cleanup action has effect for scaling CPU and memory. If cleanup action is setup for shutting down the virtual machines, the shutdown machines does not reserve any resources. If cleanup action is set for leaving the machines running, all running machines needs the resources even though they are not used for application processing.
Virtual machines are configured per user, which means that if one site would need sequencing on windows 7 but two users would be working on sequencing simultaneously, two windows 7 machines needs to be configured. If these two users would be working on two sites, they would typically need the virtual machines configured for both sites. Reason for configuring similar machines for all sites is because virtual machine tasks are typically automated, which allows leaving the tasks running while working on another site. Because the virtual machines would be allocated for running tasks, they can not be used for other site simultaneously. Using server side queuing would allow using the same machines after the tasks for another site has been completed, but this would be trade off with between system resources and time needed for processing applications.
Dynamic memory configurations are a great way for sharing memory between workloads as it allows loaning unused memory for a workload having the need. Typically dynamic memory setup works well as long as it is not misused, it means that minimum memory limit should not go below the absolute minimum needed for workloads. It is especially important for SQL server instances, because of the setting “minimum memory per query”. If the minimum memory for the queries is setup to be total of 4GB, your minimum limit for dynamic memory can not be lower than 4GB + memory needed for other processes running on SQL server. Because the hypervisor used for configuring dynamic memory does not know the SQL configurations, it is possible to assign memory below the value actually needed. This being possible doesn´t mean it works, it would cause SQL server to crash and is a common reason for abandoned AppDNA tasks.
When virtualizing AppDNA environment, CPU will be virtualized too. As CPU is typically idling rather than being fully utilized it is possible to build rather large setups with only few physical CPU cores. SQL instances are the most CPU intensive workloads on AppDNA setup. As a rule of thumb, every physical core can be virtualized for up to 8 virtual cores. This means that relatively good single database setup with four virtual machines could be run on single dual core processor. However, recommendation is to use minimum quad core processors.
AppDNA setups are not dependent on any specific type of storage or storage setup, except the SQL and virtual machine performance being dependent on the disk performance. In addition to SQL performance considerations, virtual machine snapshots are the second biggest factor for scaling the storage. As snapshotted disks needs to be merged during operation, it is a direct performance issue. Inadequate storage with multiple snapshots of same virtual machine will slow down reverting to snapshot and actual operations on the virtual machine, it may also cause the virtual machines become unresponsive. Also a consideration for performance impact of snapshots is in the storage type when using SAN, snapshots on block based storage behaves differently than the ones on storage based on file system (ie. ISCSI vs. NFS). If virtual machines are running on the same disks as the SQL server databases, increased number of snapshot has also direct effect on SQL performance, which in turn effects time needed for importing and analyzing the applications.
1GB network is recommended as 100MB network connection will be a bottleneck when running SQL instances in datacenter outside of physical AppDNA server. If virtual machine storage is also located on SAN in datacenter while virtual machines are virtualized on standalone physical hardware, 10GB network connection is recommended for optimum virtual machine performance.
AppDNA environments are fairly simple, but it can be challenging to scale the resources when entering to multitenant setups. The smaller setups will require relatively large pool of resources compared to larger setups. This is caused by the increased amount of idle following the added resources for workloads. As smaller environments are typically more utilized than the larger ones, required resources do not scale up in linear with the added tenants. This means that there is a cut off point where adding resources makes any difference. From sizing point of view, it is my recommendation to fully virtualize the AppDNA environments as it allows dynamic resource allocation.