1. <noframes id="nrulw"></noframes>
        <noframes id="nrulw"><small id="nrulw"></small></noframes>
          <ins id="nrulw"><option id="nrulw"></option></ins>
          1. 代寫Cloud Computing Spring 代做Automatically Scaling Web

            時間:2024-03-26  來源:  作者: 我要糾錯

            Cloud Computing Spring 2024
            Assignment 1: Building an Automatically Scaling Web Application
            Deadline: Monday, April 15, 2024
            1 Aim and Scope
            In this assignment we will build a small automatically scaling testbed for a (very) trivial Web
            application. The goal of the assignment is to become familiar with all facets of scaling Web
            applications, which will increase your understanding of the low-level / fundamental implementation
            details of Cloud systems. As we have discussed in class, we could deploy such a web application
            within a virtual machine or within containers. To keep things manageable on a single workstation,
            or laptop, we will constrain ourselves to a single host and make use of containers. In order to
            simulate saturated servers, the Web application will be single-threaded and can be rate limited on
            purpose. Do note that this assignment can be implemented similarly using virtual machines, and
            also can be easily extended to a distributed system consisting of multiple hosts. Both of these are
            out of scope of this assignment however.
            As has been discussed during the lectures, a number of components are required to create an
            automatically scaling Web application. These components are summarized in the following figure:
            load balancer
            container engine
            to start/stop
            will run in container engine
            As can be seen, the assignment is centered around a Web application, deployed in a container,
            that can be scaled out when the incoming load requires so. A load balancer is used to balance
            the load over multiple instances of the Web application (or a single instance if this is sufficient to
            sustain the load). It is the responsibility of the scaling controller to monitor the incoming load
            and to scale out or scale in when required. The load generator is used in experiments to evaluate
            the system.
            2 Requirements
            The goal of this assignment is to create the setup as depicted in the above figure and to perform
            a number of experiments. In a report that must accompany your submission, your setup needs to
            be well documented, the architecture must be described, and must include the experiments that
            have been conducted. As an actual Web application to scale you will be provided with a small
            and trivial object store API. This application is single-threaded, can be rate limited on purpose
            and can insert random delays in serving HTTP requests to mimic a server under load (both of
            which are configurable). See Appendix A for details.
            Within this assignment, you will be using podman as container engine. As described above,
            we have chosen to use containers for this assignment because it is easier to work with than a
            fully fledged virtual machine hypervisor and requires (significantly) less memory and disk space
            for hosting multiple instances of the developed Web application. Some tips & tricks using podman
            can be found in Appendix B.
            The scaling controller and algorithm are to be designed and developed by you. You have free￾dom in designing the scaling algorithm. This algorithm can be rule-based, based on regression, or
            use a sliding window, etc., etc. We recommend that you conduct a number of ‘calibration’ exper￾iments in conjunction with the development of the scaling algorithm (see also in the enumeration
            below). The information obtained through calibration should be used to design and tune a scaling
            algorithm for your scaling controller. For instance, design rules/thresholds for scaling decisions.
            It might be worthwhile to first set a particular target response time, so to make a Service Level
            Agreement, that you want to achieve also under increasing client load. Finally, the project is
            concluded with a set of experiments to evaluate the effectiveness of your scaling controller.
            The following table summarizes the requirements regarding the different system components:
            Component Requirement
            Web application Provided on Brightspace.
            Container engine podman must be used.
            Load balancer Required. You are allowed to write your own (simple) load balancer,
            but are also free to pick an existing one such as HAProxy.
            Load generator Required. You are allowed to either write your own request generator
            or to use an existing one (e.g., jMeter (Java based) or Locust (Python
            based)). We strongly recommend you to first design your experiments
            and then see whether an existing project can be used to perform your
            Scaling controller Required. You must write your own scaling controller. Informa￾tion is to be collected from the load balancer and/or Web application
            instances. The scaling decision is carried out by executing podman
            commands or API calls. See also Appendix D. This scaling controller
            is to be implemented in a programming language of choice.
            With regard to the experiments to be conducted within the project and to be presented and
            discussed in the report:
            Experiment Description
            Functionality test Perform a functionality experiment (or integration test) for the load
            generator and container engine. This is to make sure that the basics
            work well.
            Calibration experi￾ments
            Required. Conduct a number of calibration experiments. You likely
            want to conduct these experiments in conjunction with developing your
            scaling algorithm.
            (a) Determine the saturation point of a single container. Play with rate
            limiting and the random delays to see what effects this has on response
            time (latency), request throughput, CPU utilization, etc.
            (b) A similar experiment, with different amounts of containers, to get
            an impression of how the performance would scale.
            (c) Determine the time required to spawn new containers.
            Final experiment Required. Conduct two meaningful final experiments that evaluate
            and demonstrate the effectiveness of the automatic scaling that you
            have implemented. These experiments must investigate the response
            of the system to an increasing and decreasing number of client requests
            as to demonstrate that the system will automatically scale out and in.
            Investigate the response time of the scaling system and try to improve
            this to show that the number of failed requests can be minimized or
            (preferably) fully eliminated such that some SLA is adhered to. Things
            to experiment with include changing the rules for scaling decisions used
            by the scaling controller, optimizing the method or timing of spawning
            new containers (such that they can be spawned in less time), reducing
            oscillation, etc.
            3 Development Environment
            To work on this assignment you need administrative (root) access to a Linux installation. This
            could be your own laptop or workstation, however we strongly recommend to create a dedicated
            virtual machine for this assignment. You can use a setup similar to your setup for Homework 1.
            Make sure to assign multiple cores to this virtual machine, this is important for the experiments.
            The required disk space for the virtual machine depends on the OS you want to use within the
            containers. In the case of the small Alpine OS, 4 to 5 GB should be enough, otherwise consider
            10 GB. Document the Linux distribution used in your report.
            4 Submission and Assessment
            Teams may be formed that consist of at most two persons. In a team of two members, we
            expect that both members contribute to the implementation of the system and execution of the
            experiments. The deadline is Monday, April 15, 2024. Submit your assignments according to the
            instructions below. In case there are problems with the team work, contact the lecturer by e-mail.
            As part of the report you must list the contributions of each team member to the project.
            The maximum grade that can be obtained is 10. The grade is the sum of the brackets. When
            scoring each component we will consider whether the functionality is complete and works, as well
            as own initiatives and ideas that clearly surpass the assignment’s requirements.
            ❼ [4 out of 10] Completeness and functionality of the submission.
            ❼ [2 out of 10] Quality of the content and layout of the report.
            ❼ [1 out of 10] Calibration experiments (design and report).
            ❼ [3 out of 10] Quality and depth of the conducted experiments to evaluate the effectiveness
            of the scaling controller. This comprises the experimental design, implementation of the
            necessary load generator, reporting and interpretation of the results.
            Assignments must be submitted through Brightspace. For each team a single submission is
            expected. Please note your names and student IDs in the text box in the submission website.
            Ensure that all files that are submitted include names and student IDs.
            The following needs to be submitted:
            Web Application ❼ Listing of commands or Containerfile/Dockerfile to generate the con￾tainer image for the web application.
            ❼ Web application source, if modifications were made.
            Load balancer ❼ Configuration file.
            ❼ If developed by yourself: source code.
            ❼ If run within a container, listing of commands or Containerfile or
            Dockerfile to generate this container image.
            Scaling controller ❼ Source code.
            Request generator ❼ If developed by yourself: source code of the generator.
            ❼ Configuration files, and source code of associated extension modules
            if required.
            Report Report in PDF format (please no Word files), in which the following is
            ❼ Description and explanation of the implemented architecture.
            ❼ Include your own system diagram that reflects your designed and
            implemented architecture.
            ❼ Description of development environment (e.g. which Linux distribu￾tion was used in your virtual machine).
            ❼ Choices made during implementation.
            ❼ A clear explanation of the scaling policy design. Use a diagram or
            concise pseudocode listing in your explanation.
            ❼ Report on the design and results of the ‘calibration’ experiments.
            ❼ Report on the design and the results of the conducted experiments
            to evaluate the effectiveness of your scaling controller. This includes
            motivation and implementation of a load generator.
            ❼ List the contributions made by each team member to the assignment,
            so it is clear who worked on which parts. Note that we expect that
            both team members contribute to the implementation of the system
            and execution of the experiments.
            Finally, please note the following:
            ❼ All submitted source code and reports may be subject to (automatic) plagiarism checks
            using Turnitin and/or MOSS. Suspicions of fraud and plagiarism will be reported to the
            Board of Examiners.
            ❼ The use of text or code generated by ChatGPT or other AI tools is not allowed. You are
            required to implement the requested source code yourself, and to write the report yourself.
            ❼ We may always invite teams to elaborate on their submission in an interview in case parts
            of the source code or report need further explanation.
            ❼ As with all other course work, keep assignment solutions to yourself. Do not post the code
            on public Git or code snippet repositories where it can be found by other students. If you
            use Git, make sure your repository is private.
            In these appendices we have collected some background information on the Web application that
            is provided to you, a number of directions and suggestions for using Podman, and some general
            tips and tricks for components of the assignment.
            A Web Application API
            As Web application you are provided with a trivial object store application based on a RESTful
            API. The application is written in Python using the Flask web framework. Objects are stored
            by name (key or object ID) in a directory on the file system. This object ID is unique. The
            application only works with text files (so not with binary image or PDF files), keep that in mind
            in case you want to experiment with large files.
            To deploy the application within a container, we recommend to install Python 3 packages
            within the container image first. After that, create a Python venv1 and install flask limiter
            and flask restful using pip.
            In order to make the containers that host the Web application stateless, an external directory
            will be mounted within the containers (so all containers have access to the same external directory
            and thus to the same collection of objects). To keep things simple we did not consider problems
            arising from concurrent access to the objects such as race conditions (we will leave this for another
            The application allows rate limiting and random delays to be configured. These customization
            opportunities are there to support the experiments to test the scaling functionality. For the
            configuration of rate limiting, refer to the bottom of the source file of the web application. By
            default random delays are introduced when serving HTTP requests, to mimic a server under load.
            These can be configured (and also be disabled) using the variables just above the definition of the
            function random delay.
            The API implemented is as follows:
            GET / Return a list of object IDs.
            DELETE / Delete all objects.
            GET /objs/<obj id> Return content of object with ID <obj id> or 404 if object
            does not exist.
            PUT /objs/<obj id> Store provided content within object with ID <obj id>.
            Creates a new object if an object with this ID does not yet
            exist, otherwise it overwrites the existing object.
            DELETE /objs/<obj id> Delete the object with specified ID. Returns 404 if the spec￾ified object does not exist.
            GET /objs/<obj id>/compress Return BZ2-compressed object in base64 encoding of object
            with ID <obj id> or 404 if object does not exist.
            B Working with podman
            We will be using podman as container engine. podman automatically handles the virtual network
            and additionally provides an easy way to store state outside of the containers in order to make
            our container that hosts the Web application stateless — important to simplify scaling!
            To install podman refer to your solution for Homework 1, or use the development virtual
            image provided by us (see Brightspace). We strongly suggest to create all containers as the root
            user, to ensure that networking performs as expected. In this case, containers will be stored in
            /var/lib/containers. How much storage space you need depends on what Linux distribution
            you want to use within your containers. If this is a tiny distribution like Alpine, then 200 to 300
            MB storage space should be enough. If you want to use a distribution like Debian, Ubuntu or
            CentOS, count on 2 to 3 GB.
            B.1 Commands to create container images
            podman can create containers using Dockerfiles (or Containerfiles with the same syntax). Many
            use another tool called buildah (which actually came before podman) to build container images.
            buildah can be installed on Ubuntu/Debian with a single apt-get install buildah, or dnf
            install buildah on Red Hat derivatives. buildah can handle Dockerfiles, but can also build
            images from scratch. An advantage of building images from scratch is that you have full control
            and can optimize for size.
            A new container image can be created from scratch by starting with a base OS image. After
            image creation, commands can be run inside the container to continue configuration. For the
            scaling web application, you will create containers that are based on a particular container image
            (see later on).
            In the interest of saving disk space, one can consider to use Alpine Linux. This is a (very)
            small Linux distribution that is often used within containers. To initialize a new container image
            based on Alpine Linux:
            container=$(buildah from alpine)
            Subsequently, we can run commands within the container2
            buildah run $container -- ls /etc
            Within the container, you might want to install additional packages (Python anyone?). The exact
            instructions depend on the distribution you have selected. In case you are working with Alpine,
            you can install Python 3 by executing the following commands:
            buildah run $container -- apk update
            buildah run $container -- apk add python3
            You can search the package database as follows:
            buildah run $container -- apk list ’*haproxy*’
            (yes, Alpine also has HAProxy packages in case you want to create a container for your load
            Files can be copied into the container using the copy subcommand, e.g.:
            buildah copy $container myfile.txt /root
            Finally, it is important that the changes made are committed to a named image. In this case we
            will use testcontainer as name. After commit, the image will be visible within podman as well.
            buildah commit $container testcontainer
            Note that the same can be achieved using a Dockerfile with RUN and COPY verbs. The command
            to build containers from Dockerfiles is buildah bud.
            Additional Resources For more information on buildah, refer to for instance:
            B.2 Starting the Web application on container startup
            Do not forget to ensure that your Web application is started on container startup. This can be
            achieved by configuring a container command or entrypoint. For example, to start the Python
            built-in webserver, which serves files from the specified directory, upon container start up:
            buildah config --cmd "" $container
            buildah config --entrypoint "python3 -m http.server 8000 --directory /tmp" $container
            buildah commit $container testcontainer
            2On Debian 11 this does not appear to work out of the box, the following environment variable is required:
            export BUILDAH RUNTIME=/usr/bin/runc.
            B.3 Starting container instances
            From images, container instances can be started. Multiple container instances can be started
            from a single image, and this is exactly what we need to ‘scale out’ the Web application. This is
            achieved using the podman command. Note that this will not create full copies of the container
            image, rather, the image remains read-only and an overlay file system is placed on top of it to
            catch any writes.
            The container for your Web application is supposed to be stateless. This implies that when
            the container is no longer necessary (scale down), it can be safely deleted as no valuable data is
            stored within the container. A special command line flag is present for this purpose, such that a
            container is automatically deleted upon container shutdown. Using the following command, such
            a container can be instantiated and the entrypoint will be launched automatically:
            podman run --rm --name mycontainer testcontainer
            As you can see the testcontainer image is used to create a container named mycontainer. You
            will note that the container entrypoint process remains in the foreground. To avoid this, add the
            -d command line flag.
            The currently active containers can be inspected using the command podman ps. Now, how
            can we access the Python process running on the internal container network? We need to retrieve
            the internal IP address. To do so, you can use the command:
            podman container inspect mycontainer
            This gives a lot of information about the container. Search for IPAddress to obtain the internal
            IP address. Through this IP, you should be able to access the Python webserver on port 8000.
            You can also map the container’s port to the host port using the -p option. But note that in the
            context of this assignment, you will only want to expose the port of the load balancer, the ports
            of the Web application instances remain internal!
            Finally, to stop a container you can use: podman stop.
            B.4 Mounting a directory within a container
            For the Web application you need to ensure that all containers have access to the same directory
            in which the objects are stored. First make sure you have created such a directory on the host
            (we use /srv/objects). In your container image, you want to create a mountpoint, for example
            /objects. With this in place, add the following command line option to the podman run command
            to mount the host directory /srv/objects within the container:
            -v /srv/objects:/objects
            C Suggestions on the load balancer
            You may write your own load balancer or use an existing one such as HAProxy. As you may have
            read above, Alpine does provide HAProxy packages. Therefore, it is relatively easy to set up a
            container in which you can run the load balancer.
            HAProxy allows you to read out statistics via HTTP. To enable this, you need to add a section
            such as the following to the configuration file:
            frontend stats
            bind *:9999
            stats enable
            stats uri /stats
            stats refresh 1s
            After restarting HAProxy, you can connect to port 9999 to read statistics. For instance, con￾nect to (of course replace the IP address with the correct one).
            The following URL returns machine-readable CSV output, which will be useful for your scaling
            D Considerations for the scaling controller
            The scaling controller consists of two parts that can be programmed independently (make good
            use of your team’s resources) before these are integrated. The monitoring part should monitor the
            load balancer and/or the container instances running the web application. It needs to retrieve the
            information required to make scaling decisions (should we scale up, scale down? And if so by how
            many instances?). Note that this refers to the Monitoring, Analysis and Planning phases of the
            MAPE feedback loop. If you chose to use HAProxy, you can monitor the haproxy daemon which
            has an option to provide you with statistics
            The podman part needs to be capable of creating new container instances, stopping instances,
            listing all instances (and their IP addresses) and all other container management utilities you
            need in order to make the scaling controller work. This is the (final) Execution phase of the
            MAPE loop. podman commands or API calls might be blocking by default, in which case you
            want to look into asynchronous calls or multi-threading in order to make your scaling controller
            more responsive. This way, you can continue monitoring, while the podman commands are being
            executed in a different thread.
            After instructing podman to start or stop a container, you also need to update the configuration
            of the load balancer. How exactly this should be done depends on the load balancer have you
            chosen to use. In the case of HAProxy there is no clear runtime API to update the list of
            servers. The most straightforward way to achieve this is to have your scaling controller regenerate
            the HAProxy configuration file, send this configuration to the load balancer container (or use a
            volume mount?) and reload HAProxy. Hacky, but it works and it appears this is used in practice
            podman can be controlled through shell commands, but also via its RESTful API. This API
            is documented in detail: https://docs.podman.io/en/v3.2.3/_static/api.html.
            While you can target this RESTful API directly, fortunately also language bindings exist for at
            least Python and Go. We give a small example of the Python API. Before you can use this API,
            the module needs to be installed with pip3 install podman.
            Obtain a list of names of defined containers:
            from podman import PodmanClient
            client = PodmanClient(base_url="unix:///run/podman/podman.sock")
            l = [c.name for c in client.containers.list()]
            Get a handle on a container and if it is running print the IP addresses of this container3
            from podman import PodmanClient
            client = PodmanClient(base_url="unix:///run/podman/podman.sock")
            c = client.containers.get("testcontainer")
            if c.status == ’running’:
            Containers can be stopped with the .stop() method. The method .wait(condition=’running’)
            waits (blocking) until a container is running.
            3The podman in the dictionary access is the name of the default container network, see the command podman
            network ls.
            The Python module has extensive documentation, use the help command in an interactive Python
            shell. We could not find this documentation online.
            E Testing the system
            In order to test the completed system, you want to use a HTTP load generator. Options are
            writing such a generator yourself, jMeter, Locust or something else you find to be suitable. For
            your experiments it is important to first design your experiments and after that decide on a load or
            traffic pattern generator to use. You do not want to be limited in your experiments by a previously
            selected load generator.
            Locust is Python-based and works as a command-line utility. First, you need to write a locust file
            (refer to the website https://docs.locust.io/en/stable/quickstart.html for an example).
            After that you can start locust:
            locust -f mylocustfile.py --headless -u 10 -t 300s -r 0.5
            Where -u configures the number of (concurrent) users, -t configures the runtime of the experiment
            and -r configures the rate in which clients are spawned. The values for the parameters that are
            given are just examples, you should set up your own experiment.
            請加QQ:99515681  郵箱:99515681@qq.com   WX:codehelp 



          2. 上一篇:菲律賓機場有什么保關服務?有哪些機場?華商簽證分享
          3. 下一篇:返回列表
          4. 無相關信息

          5. 關于我們 | 打賞支持 | 廣告服務 | 聯系我們 | 網站地圖 | 免責聲明 | 幫助中心 | 友情鏈接 |

            Copyright © 2023 kmw.cc Inc. All Rights Reserved. 昆明網 版權所有
            ICP備06013414號-3 公安備 42010502001045