SCHYNDELWORKS? WEBSITE PROJECT

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 8070. 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 ease of use, the server must be capable of dealing with misspelling/capitalization issues. 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 .gif 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. • You will need to create users alice & dean with password ITIS • All necessary user key/password/group files for auth to be placed at /etc/apache2/schyndel/server_root/auth) BR (A).9 All content served by the web server must respond with the following Response Header: "X-Served-Via: Web-Server-A" 4 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 8060 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 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 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 (bonus-business-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) │ └─── <> │ ├─── /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