If you are a Managed Hosting customer, this topic doesn't apply to you.
Online learning models create new demands for the IT environment to provide higher performance, fast response times, and high availability. Not only are institutions growing and supporting greater numbers of online users, but users are also interacting with the system in new ways that generate substantially greater system load. Users tend to stay online for much longer periods of time and have greater interactivity with their online courses. The technology must therefore support large numbers of users who concurrently access the system and require rapid response times so that they can interact without noticeable delays. Hardware sizing enables the provisioning of hardware for scalable and cost-effective service delivery based on your institution's current and future growth needs.
Hardware sizing is a process wherein data is gathered on usage scenarios and then through analysis one may predict the optimal hardware configuration for a given usage scenario. The information in this section helps Blackboard Learn clients achieve high service levels and reduce risk by properly configuring and sizing the implementation of Blackboard Learn application and database servers based on performance testing conducted by the Blackboard Performance Engineering team.
Blackboard recommends leveraging both physical and virtual configurations. For years, the Blackboard products have been deployed in distributed manner across multiple physical servers. This configuration remains as the primary option for availability and scalability. In recent releases, many Blackboard customers have introduced virtualized configurations within a physical server using technology such as VMWare, Citrix XenServer, and Red Hat Xen. The combination of both physical and virtualized configurations has introduced resiliency, scalability, and high performance. In Blackboard Learn Release 9.1, Blackboard introduced a 100% 64-bit offering for all certified and supported operating systems (OSs) as an additional deployment approach to integrate with physical and virtual configurations.
This information is intended to provide guidance. It is not intended as a service level agreement. Deployments will differ from institution to institution based on a variety of factors including the usage of the application. To learn more about systems architecture design and detailed sizing questions, contact your Blackboard Account Manager.
Sizing is a three-step process consisting of two modeling exercises and performance testing. The modeling exercises are used to gather statistical evidence about how users interact with the system. The data generated from these exercises is subsequently used in a series of performance tests. Performance tests help quantify what the system will look like under hypothesized workloads and scenarios.
The process begins with understanding how Blackboard clients have used the product in the past. This form of sampling is called behavior modeling. The objective of this form of sampling is to gather meaningful data representing the following:
- Who is using the system?
- What is being done?
- Where are they performing their operations?
- When are they performing their operations?
- How long are users spending performing their operations?
Predictive modeling is used for new performance testing new features. Little information can be collected about a feature that has not been built. Because of this, Blackboard hypothesizes user interactions with these new features.
The data collected from both modeling exercises is then used for performance testing and benchmarking. Performance benchmarking is conducted by Blackboard at the Blackboard Performance Laboratory. Performance testing and benchmark activities focus primarily on the performance (response times exhibited by users) and scalability of the system (utilization of system resources such as CPU, memory, and I/O).
Since Release 8, Blackboard's Performance Engineering team has executed more than 4,000 hours of regression testing and benchmarking of Blackboard Learn using virtualization technologies such as VMware ESX, Citrix XenServer, and Red Hat Xen.
Many customers have made virtualization part of their deployment approach.
Virtualization enables multiple instances of Guest OS to be deployed on each physical server. Server processor, memory, storage, and networking resources are shared across multiple virtual machines, yet each virtual machine (VM) and OS instance can have direct control over specific system resources. Blackboard Learn can then be installed and operated on each VM in much the same way as running each instance on a separate physical server.
Following are the two key reasons exist for implementing virtualization in the application tier:
- Modern CPUs are so powerful that a single instance of the OS and its application software components typically cannot fully utilize the CPU. It is more cost-effective to add additional memory to a server and divide the server resources into multiple virtual machines than it is to buy more servers.
- Virtualization greatly simplifies provisioning and management of the Blackboard Learn environment.
Most of the virtualization packages deployed in Blackboard production environments include software tools to enable administrators to quickly and easily clone an image of a VM, including the OS and all application instances. This cloned VM image can then be quickly provisioned to a new VM when, for example, greater capacity is needed. Cloning also helps to ensure that all instances of the application are deployed in identical configurations, greatly simplifying ongoing maintenance of the environment.
Blackboard's recommended configuration is based on a scalable reference architecture that takes advantage of today's latest technologies to support a rich online learning or distance learning model. In addition, this architecture offers superior performance and scalability as well as predictable service levels. This information is based on performance testing and benchmarking conducted by Blackboard to achieve maximum performance throughput for each configuration.