Most Blackboard administrators would agree that they strive to develop and maintain a stable Blackboard Learn environment. One of the most important factors to achieve that goal is a good foundation.
Earlier we used the example of a community, having good streets along with enough power and water will allow a community to support many residents. In this case, we need to examine the hardware and software requirements along with the different architecture options for our Blackboard Learn instance or virtual community. After we review our options, we can create a decision diagram that can help us decide what architecture options are right for our plans.
A one server architecture is the simplest installation of Blackboard Learn for an organization. A one server instance means that your database, application, and collaboration servers all reside on the same server.
The following diagram shows the structure of a one server architecture:
This can be a great option if we only have a few classes and a limited number of users. It's also ideal if you don't expect increased class or user growth in the near future. Many small organizations or developers use a one server architecture.
The drawback of a one server instance is the one point of failure. If any hardware or software issues occur, the Blackboard Learn environment is down for users. This environment also creates issues when your organization needs to expand their environment for growing users and course offerings. If the instance grows too big for the hardware and software it operates on, then it will require a move that will bring more server downtime. More downtime means users' work and course development is delayed.
A two server architecture is very similar to a one server, however the database has moved to a new server. This allows our server to use more processor time on Tomcat and our IIS or Apache server. The issues we brought up earlier in a one server architecture still remain the same.
The following diagram shows the structure of a two server architecture:
A multiple server instance offers the best starting point for any organization. Multiple servers split Blackboard services into a server for our database, multiple servers host our Tomcat and IIS or Apache servers, and even a server that hosts our collaboration server. This architecture requires additional hardware. All the servers will need to put course and user files in one central location for every server to have access. We can accomplish this with the use of a network storage device or SAN.
This design also requires a load balancer to be added as well. It creates a single point of access, so when our user types http://blackboard.myorganization.com into their browser, the load balancer will direct the response to one of our application servers, bbapp1, bbapp2, or bbapp3.
Most Blackboard administrators would recommend an organization with plans to expand users and course offerings to implement this type of instance. When the organization grows, additional application servers can be added to meet increased load with little effect on the experience of our users. The diagram below offers us a view of how a two server instance can grow into a much larger instance:
While the multiple server structure does allow the easy expansion of Blackboard Learn, it doesn't completely address issues with a single point of failure. If the database server or storage device fails, the system will be down. Some organizations may turn to adding another database server or additional backup storage devices. We will address planning for a disaster and disaster recovery in Chapter 12, Logs, Troubleshooting, and Disaster Recovery in Blackboard Learn.
While Blackboard Learn instances can be created using different types of configurations, the one thing we should also examine would be where those configurations thrive. When we think of any web service, we think of servers in a rack that do one or two different things. However, with the increase in hardware loads and costs, many organizations are looking to use the latest technology options to meet their needs and stretch their budgets.
The first option that many organizations use would be virtual servers. These software created servers reside on a hardware server; however, multiple virtual servers can be on one hardware server. This option allows for the maximum use of purchased hardware to meet the needs of the organization. Blackboard Inc. does support the installation of its product on virtual server software. The two main manufacturers are VMWare and Microsoft's Hyper V.
While most of the organizations I have worked with have used some type of virtualization, we may need to convince administration to use virtual servers. One of the biggest reasons I have shared with administrators is the ease of duplicating the server and the ability to bring the system back up. When built correctly, you can bring a virtual server back up in another location within minutes instead of hours. While we won't cover the installation and setup of virtual servers in our discussions, it is important that we understand that it is an option when planning our Blackboard Learn architecture.
Blackboard does offer managed hosting for clients. This service has Blackboard's engineering teams to take care of your instance. However, according to some clients, the service does limit the amount of control administrators have to the backend.
Now that we reviewed the types of instances and options for our Blackboard Learn instance, let's discuss what instance we should build. If we currently are looking to have a small user pilot to test our Blackboard Learn, we can start with a single server instance that can make it easy for us to collect helpful data on how instructors and students will use Blackboard Learn. If we are migrating from another LMS product, we can use course and user storage amounts, user activity, or any other data to provide additional insight.
Tip
In Chapter 9, Security, Reporting, and Configuration in Blackboard Learn we discuss the collection of different types of data to improve the performance of our Blackboard Learn environment and the use of the BbStats tool that can greatly help collect data from within a Blackboard Learn pilot. When collecting our data we should work to find the averages based on multiple weeks when our environment has peak usage.
We also need to review some major questions that will help us plan what installation we will implement. First we should review how much growth our instance will see in the coming years:
If Blackboard Learn is replacing another learning management system (or LMS), and how many users were there in the previous LMS?
How many users do we expect will be in the LMS three years in the future?
Now we should look at course growth:
How many courses will be on this instance?
Will Blackboard Learn be only used for online courses or both online and supplementing face-to-face?
If we are moving from another LMS, how much disk space did an average course use?
Will instructors actively use the tools within Blackboard Learn?
Do we plan to allow video and multimedia files?
Will our instance also host the organization's internal committee and communication groups along with courses?
How quickly will your organization be developing new courses and how many will there be in three years?
Then we look at what requirements come from your IT department:
How mission critical is Blackboard Learn to the organization?
How much has the IT department/organization budgeted for a Blackboard Learn implementation?
Now that we have covered all these questions and hopefully collected some data from our previous LMS or pilot project, let's look at some tables to help us analyze our information:
This table will help us review the current data sets that we have. Based on that information we can understand what type of instance we currently need. The first row, Current Active Users, compares the number of users who have logged into our system or we expect to login to our system over a 90 day period. The second row looks at the combined file storage for course and user files. These files are normally associated with courses and student submitted content within them. Our third row discusses the growth or adoption rate over the next five years of the Blackboard Learn environment.
The next two rows review the number of courses created and kept on the system for an instructional term and how long these courses are kept within our environment. Some courses may never go away or some institutions create new ones each term. Our course retention normally follows a set institutional policy. The next row asks about the use of Blackboard Learn's assessment tool with face-to-face or on campus courses. The assessment tool is the heaviest process on our Blackboard Learn environment. If the tool is used to give an assessment to over 50 students at once in a lab setting, our architecture may create an unacceptable experience for users. Now let's review the broader questions we mentioned earlier by using this table:
While our first table reviewed the current data we have, our discussion here is about the expected use and growth. Select answers to the questions in our form. If most of them are classified in the Small and Stable or Large and Stable columns, our environment will probably not see any growth so planning for expanding the Blackboard Learn instance is not a high priority. Our organization might look at a one or two server instance due to this fact. If most of our selections are within the Small and Growing or Large and Growing columns we will want to plan for some expansion and may want initially implement a multiple server architecture that will allow for the addition of application servers when needed.
While deciding the architecture of the Blackboard Learn environment for our organization we have many variables like server types, processors, memory, and organizational budgets. Even with these variables, this discussion should offer some clarity. In Chapter 9, Security, Reporting, and Configuration in Blackboard Learn we will learn how to improve the current architecture by tuning the Blackboard Learn, Apache or IIS, and Tomcat settings to get the most out of our architecture.