Project Background and Description

1
SCHYNDELWORKS™ WEBSITE
PROJECT
Semester 1, 2019
Note that this is a simulation of a typical project specification. For assignment
submission dates and details, see the Canvas shell,.
OVERVIEW
1. Project Background and Description
As the 2018 technology placements have been completed, SchyndelWorks now has a team
of technology graduates that can help them setup their public facing website. These
graduates will work with the cloud engineer to deliver a product that meets all the business
requirements specified in sections 3 & 4 of this document.
2. Project Scope
The web development team has already created the necessary code (PHP) for the
SchyndelWork‟s public facing websites. This code must now be deployed to a public facing
website hosted on the cloud.
3. High-Level Requirements
The new system must be able to meet the following business requirements
2
Business Requirement (A): Creation of Web-Server-A
BR (A).1 – Archive: https://archive.apache.org/dist/httpd/
• After looking at the business requirements, the cloud engineer has specified that we
create a new VM to host Web-Server-A on a “t2.micro” ec2 instance of AWS (or
equivalent if using azure).
• On this VM compile & install a version of apache 2.4.25 from source.
• Since performance is a key concern, might be good to use an appropriate MPM.
Note: The cloud engineer is adamant that Apache installed via a package manager
for Web-Server-A will NOT NECESSARILY be better/easier/meet all requirements.
But, could still very likely be a possible path to go down.
BR (A).1.1
Web-Server-A will initially be used as staging server so it must serve http via port 8010.
Ensure that the port firewall is open & visible.
BR (A).1.2
Server should be installed at /etc/apache2/schyndel/server_root
BR (A).1.3
All necessary user key/password/group files for auth to be placed at
/etc/apache2/schyndel/server_root/auth
BR (A).1.4
As PHP web developers have been contracted to create site content, your website should
have the capability of executing & serving PHP scripts
BR (A).1.5
• To allow continuity of business, SchyndelWorks requires all work done to be
documented.
• You will need to create “business-requirement-a/a-report.txt” which documents all work
that you have undertaken.
• Your report must document all the work done as a part of each business requirement.
• If you make any changes to configuration files, it must be commented & reference the
business requirement id.
• For example, when setting the port, you will need to add the following comment in your
configuration file
# BR (A).1.1: As per requirement, changed port from 80 to 8080
BR (A).1.6
They‟ve asked for a clear description as to why escaping and encoding URLs is important.
The Cloud Engineer has asked you to explain in a comment in the configuration (and in
you‟re a-report.txt), why the changes are needed to be made to Apache as described in this
URL: https://canvas.instructure.com/doc/api/file.object_ids.html
3
BR (A).2
To allow audit, the server must allow „server-info‟ and „server-status‟ to be implemented.
Only username „audit‟ should be able to do this.
BR (A).3
• Documents should be served from /etc/apache2/schyndel/document_root
• The content to be served has already been written and the source code is available at
the site labelled in this document as WEB_CONTENT_URL (See Canvas Spec for
actual URL)

Hint: You can use the following commands to download the content:
mkdir /etc/apache2/schyndel/document_root
cd /etc/apache2/schyndel/document_root
wget WEB_CONTENT_URL
unzip master.zip
rm master.zip
mv -f schyndel-works-site-master/* .
rmdir schyndel-works-site-master
BR (A).4
The default document to be served is index.html then index.shtml then index.php
BR (A).5
Your server must permit Server Side Includes (SSI) for files with the .shtml extension.
BR (A).6
Your site must not permit .zip files from being served.
BR (A).7
• Content in the /secure-basic folder must be protected via basic auth
• You will need to create users bob & charlie with password ITIS
• All necessary user key/password/group files for auth to be placed at:
/etc/apache2/schyndel/server_root/auth)
BR (A).8
• Content in the /secure-digest folder must be protected via digest auth as must the audit
feature of BR (A).2.
• You will need to create users alice & dean with password ITIS and user audit with
password ATO.
• •
All necessary user key/password/group files for auth to be placed at
/etc/apache2/schyndel/server_root/auth)
4
BR (A).9
All content served by the web server must respond with the following Response Header:
“X-Served-Via: Web-Server-A”
Business Requirement (B): Creation of Web-Server-B
Now that the staging server has been created, a production web server now needs
to be setup. This production web server will be identical to “Web-Server-A” except
the changes listed below:
BR (B).1
VM to host Web-Server-B on a “t2.micro” ec2 instance of AWS (or equivalent if using azure)
BR (B).2
Port used to serve documents should be 8020
Ensure that the port firewall is open & visible.
BR (B).3
All content served by the web server must respond with the following Response Header
“X-Served-Via: Web-Server-B”
BR (B).4
• To allow continuity of business, SchyndelWorks requires all work done to be
documented.
• Since most of the steps are similar to Business Requirement A you don’t need to create
a report, EXCEPT for all changes made to configuration files, it must be commented &
reference the business requirement id.
For example, when setting the port, you will need to add the following comment in your
configuration file
# BR (B).2: As per requirement, changed port from 80 to 8050
BR (B).5
To allow audit, the server must allow „server-info‟ and „server-status‟ to be implemented.
Only username „audit‟ should be able to do this. Ensure the username „audit‟ is set up as in
BR (A)
5
Business Requirement (C): Performance Testing
BR (C).1
• To convince the cloud engineer of your configuration choices, you are required to
produce a report.
• This report requires you to conduct benchmark OR perf tests (choose ab or httperf) on
apache.
• You should run at least 3 load tests on apache & then average out the results.
• The scripts to load test are /load/cpu.php & /load/io.php.
• Based off estimates from business, your load tests need to allow for
o /load/cpu.php has a concurrency of 10 & test 150 requests
o /load/io.php has a concurrency of 10 & test 200 requests.
• This report can be written as a word file but MUST be submitted as a pdf
(businessrequirement-c/c-report.pdf).
• It is important that you take valid screenshots of the results of each benchmark test that
is carried out. Please add these to your report.
• (Hint: Since the VMs could differ in spec, might be good to factor that into your report)
o On the VM you may need to install:
 apt-get install apache2-utils (this gives you access to ab)
 apt-get install httperf (this gives you access to httperf)
BR (C).2
• To allow continuity of business, SchyndelWorks requires all work done to be documented
in your report.
• Any and all changes made to configuration files for this BR must be commented &
reference the business requirement Identification Number (BR ID).
6
Business Requirement (D): Creation of Load-Balancer
• Since SchyndelWorks expects a large volume of end users to use their site, they would
like to serve content from either Web-Server-A or Web-Server-B via a Load-Balancer.
• As a part of this requirement you will be creating a new VM that will be used as a
loadbalancer.
• The cloud engineer has instructed you to use “t2.micro” ec2 instance of AWS (or
equivalent if using azure) for your load-balancer to prevent network saturation
constraints).
BR (D).1
• The cloud engineer has instructed you to use Apache 2.4’s mod_proxy_balancer module
to setup the load balancer.
• To accomplish this, you will need to create a new instance of apache 2.
• The engineer has specified that the apache server on this VM can be installed via a
package manager (apt-get install apache2).
• This apache server must serve content via port 80. Ensure that the port firewall is open
& visible.
• The actual content served is via Web-Server-A or Web-Server-B (this is just a load
balancer).
• The cloud engineer has instructed you to use mod_lbmethod_byrequests module as
the Load balancing scheduler algorithm.
BR (D).2
• When setting up the Load-Balancer using mod_lbmethod_byrequests, apache gives you
the option to set a “loadfactor”.
• This is the member load factor – a number between 1 (default) and 100, which defines
the weighted load to be applied to the member in question.
• The cloud engineer is unsure of what load factor needs to be applied here.
• It is your task to ascertain what is the appropriate loadfactor to be applied & configure
apache to use your loadfactor.
BR (D).3
• To convince the cloud engineer of your decision made in BR (D).2, you are required to
produce a report.
• This task is very similar to your initial benchmarking in BR (C).
• This report requires you to conduct benchmark OR perf tests (choose ab or httperf) on
apache (directing the requests to the load balancer).
• You should run at least 3 load tests on apache with an initial loadfactor applied & then
average out the results.
7
• You should then run at least 3 load tests on apache with an updated loadfactor applied &
then average out the results.
• The scripts to load test are /load/cpu.php & /load/io.php.
• Based off estimates from business, your load tests need to allow for
o /load/cpu.php has a concurrency of 10 & test 150 requests o /load/io.php has
a concurrency of 10 & test 200 requests.
• You then need to compare the 2 averaged out results sets & state in your report what
loadfactor setting is the most appropriate.
• This report can be written as a word file but MUST be submitted as a pdf
(businessrequirement-d/d-report.pdf).
• It is important that you take valid screenshots of the results of each benchmark test that
is carried out. Please add these to your report.
• (Hint: Since the VMs could differ in spec, might be good to factor that into your
calculations of the appropriate load-factor)
• Your cloud engineer has recommended that you create a new VM (“Load-Testing” VM)
using a “t2.micro” ec2 instance as your load testing server. This is done to ensure that
network throughput is not an issue.
o It has also been recommended that this particular vm (“Load-Testing” VM
only) be terminated once you have finished your load tests.
o On the vm you only need to install:
 apt-get install apache2-utils (this gives you access to ab)
 apt-get install httperf (this gives you access to httperf)
BR (D).4
• To allow continuity of business, SchyndelWorks requires all work done to be documented
in your report.
• All changes made to configuration files, it must be commented & reference the business
requirement id.
• For example, when setting the loadfactor, you will need to add the following comment in
your configuration file
# BR (D).2: As per requirement, set loadfactor to X for node X
BR (D).5
To allow audit, the server must allow „server-info‟ and „server-status‟ to be implemented.
Only username „audit‟ should be able to do this. Ensure the username „audit‟ is set up as in
BR (A)
8
Business Requirement (E): Alternative load balancing algorithm
BR (E).1
• As you have already completed “Business Requirement D”, the cloud engineer has asked
to look at an alternate Load balancing scheduler algorithm (lbmethod_bytraffic or
lbmethod_bybusyness or lbmethod_heartbeat).
• You need to pick one and compare it to the performance of lbmethod_byrequests.
• Again, your proof for ascertaining the appropriate load balancer algorithm must include
at least 3 benchmark/perf tests completed for the /load/cpu.php & /load/io.php script
with the new algorithm.
• You then need to compare it with your results from the tests you ran as a part of
“Business Requirement D” and you need to create a new report.
• This report can be written as a word file but MUST be submitted as a pdf (bonusbusiness-requirement-e/e-report.pdf).
9
4. Deliverables
A zip file containing the following assets needs to be submitted:
/Your-Directory
├─── group-info.txt

├─── links.txt

├─── /business-requirement-a




├─── a-report.txt
├─── httpd.conf (for Web-Server-A)
└─── (all auth files)

├─── /business-requirement-b



├─── httpd.conf (for Web-Server-B)
└─── <<all auth files>>
├─── /business-requirement-c


├─── c-report.docx
└─── c-report.pdf
├─── /bonus-business-requirement-d




├─── d-report.docx
├─── d-report.pdf
├─── 000-default.conf (for Load-Balancer)
└─── (any other config files changed)

└─── /bonus-business-requirement-e
├─── e-report.docx
├─── e-report.pdf
├─── 000-default.conf (for Load-Balancer)
└─── (any other config files changed)
5. Engineer’s note
While the project specification suggests a waterfall approach to time/resource allocation,
an alternative approach is to perform BR(A) and BR(B) in parallel, In addition, BR(E)
should also be reduced in priority compared to BR(C). if there is time pressure, as the
additional information it provides is relatively small and is not time-critical.
APPROVAL AND AUTHORITY TO PROCEED
We approve the project as described above, and authorize the team to proceed.

Name Title Date
Ron Van Schyndel CIO 01/02/2019
Adam Smith Cloud Engineer 01/02/2019

Leave a Reply

Your email address will not be published.