Cloud based Storage

7/27/2019 Cloud based Storage

1/34

[1]

Design and Development of Cloud based storagefor Academia

Authors

Saad Shahid (09-TE-01)

Junaid Ashfaq (09-TE-25)

Project Supervisor

Dr. Adeel Akram

TELECOMMUNICATION ENGINEERING DEPT.

UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA

July, 2013


2/34

[2]

This page is intentionally left blank


3/34

[3]

ABSTRACT

Data is driving todays ICT industry and research. The rate at which data are being

generated is immense, and its soaring everyday. The database storage systems in

most organizaons and research instuons no longer totally capable of storing ever

increasing data. The phenomenon that is rising as a soluon to this problem is cloud

based storage. The industry and leading research organizaons are increasingly

adopng cloud storage. There are several cloud storage is available commercially,

these are very good as well. But these services are proprietary and in the public

domain. An instuon such as HEC cant be trusted over those services completely.

This movates us to develop an indigenous and private cloud storage system for HEC

and its network of universies PERN, based on the architectures of public services.


4/34

[4]

UNDERTAKING

We cerfy that research work tled Design and Development of Cloud based

storage for academia is our own work. The work has not, in whole or in part, been

presented elsewhere for assessment. Where material has been used from other

sources it has been properly acknowledged/ referred.

Saad Shahid (09-TE-01)Junaid Ashfaq (09-TE-25)


5/34

[5]

ACKNOWLEDGEMENTS

Firstly, thanks Allah Almighty with His blessing for our Design and Development of

Cloud based storage for academia using PERN resources project. We would like to

express our sincere appreciaon to our supervisor, Dr. Adeel Akram for his total

support, guidance, advice and assistance throughout the process of this nal year

project.

We are very grateful to Mr. Abdul Fayyaz Chaa, Director IT, and PERN for his me

and guidance. He. The suggesons provided by him really proved helpful.

We would also like to take this opportunity to thank our beloved parents and siblings

for always mentally and nancially supporng us while doing this project.

Our fellow course mates should also be recognized for their support. Our sincere

appreciaon is also extended to all our friends, teachers and others who have

provided assistance at various occasions. Their views and ps are useful indeed


6/34

[6]

Table of ContentsABSTRACT ................................................................................................................... 3UNDERTAKING............................................................................................................. 4ACKNOWLEDGEMENTS................................................................................................ 5Table of Figures ........................................................................................................... 8

abbreviatons .............................................................................................................. 9

Chapter 1: Introducon ............................................................................................. 101.1 Problem Statement...................................................................................... 10

1.2 Objecves.................................................................................................... 10

1.3 Background ................................................................................................. 10

1.3.1 Characteriscs of Cloud......................................................................... 11

1.3.2 Service Models .................................................................................. 12

1.3.3 Deployment Models.............................................................................. 13

1.4 Our Model: .................................................................................................. 14

Advantages of Private Cloud: ............................................................................ 14

1.5 Deliverables................................................................................................. 14

1.6

Tools Used ................................................................................................... 14

1.7 Organizaon of Thesis ................................................................................. 15

Chapter 2: Literature Review...................................................................................... 162.1 An Autonomic Frame of Mind...................................................................... 17

2.2 Features of Cloud ........................................................................................ 17

2.3 Characteriscs of an autonomic service architecture ................................... 20

2.3.1 Architecture style .................................................................................. 20

2.3.2 External user and access control management ..................................... 21

2.3.3 Interacon container............................................................................. 21

2.3.4 Externalized policy management/policy Engine .................................... 22

2.3.5 Ulity Compung .................................................................................. 23

Chapter 3: Methodology ............................................................................................ 243.1 PLAN............................................................................................................ 24

3.1.1 Cloud Infrastructure Soware: .............................................................. 24

3.1.2 Cloud management server/cloud controller:......................................... 24


7/34

[7]

3.2 Client End Applicaon.................................................................................. 25

3.2.1 ATL: ....................................................................................................... 25

3.3 Server Side Implementaon ........................................................................ 26

3.3.1

Hypervisor ............................................................................................ 26

3.3.2 Hypervisor Server ................................................................................. 26

3.3.3 Management soware .......................................................................... 27

3.4 Client-Server Interfacing .............................................................................. 27

3.4.1 Web 2.0.................................................................................................... 27

3.4.2 REST: ..................................................................................................... 28

3.4.2.1 RESTful API .......................................................................................... 29

3.5 Flow of Design ............................................................................................. 29

3.5.1 Applicaon Development...................................................................... 29

3.5.2 Applicaon Deployment........................................................................ 30

Conclusion ................................................................................................................ 31future work ............................................................................................................... 32Refrences ................................................................................................................. 33


8/34

[8]

TABLE OF FIGURES

Figure 1-Service Models and Apps ............................................................................ 12

Figure 2-Private Cloud .............................................................................................. 13

Figure 3-Public Cloud ................................................................................................ 14

Figure 4-Cloud Drivers .............................................................................................. 18

Figure 5-Cloud Controler........................................................................................... 25

Figure 6-Hypervisor Type-1 ....................................................................................... 26

Figure 7-VSpehere Implementaon Model ............................................................... 27

Figure 8- Applicaon Development Flow .................................................................. 29

Figure 9- Applicaon Deployment Flow .................................................................... 30
http://k/mywork.docx%23_Toc360560345http://k/mywork.docx%23_Toc360560345http://k/mywork.docx%23_Toc360560345http://k/mywork.docx%23_Toc360560345http://k/mywork.docx%23_Toc360560345http://k/mywork.docx%23_Toc360560345http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560346http://k/mywork.docx%23_Toc360560345


9/34

[9]

ABBREVIATIONS

IaaS: Infrastructure As A Service

PaaS: Plaorm As A Service

SaaS: Soware As A Service

VM: Virtual Machine

PERN: Pakistan Educaon Research network

SQL: Sequenal Language

HTTP: Hyper Text Transfer Protocol

REST: Representaonal State Transfer

API: Applicaon Programming Interface

ATL: Acve Template Library

NSE: NameSpace Shell Extension

LAMP: Linux Apache MySQL PHP

JSON: JavaScript Object Notaon

SDK: Soware Development Kit


10/34

[10]

CHAPTER 1: INTRODUCTIONCloud Compung is the top trend among consumers, businesses and in the

technology industry. People are adopng it as a way of life. The days are gone when

the cloud is termed as a large data warehouse, now its a reality and people are

moving to the cloud increasingly.

This serves as an opportunity for the industry as well as businesses alike, seeing that

many cloud services provided in the public market many of which are well known

players in the industry like Google and Microso. The publicly provided cloud

services serves as cost eecve in the short term but have some serious issues when

it comes to security. Connecvity is also another issue because you are connected

through the internet. The sensive and high priority data like academic research

cant be trusted in public domain.Our aim is to develop a cloud that provide the public cloud like services like SkyDrive

etc. but resides in the on-premise network. This oers high security with high speed

connecvity as it will be using PERN network which is in Gigabit range. It is also

integrated with the users windows. [1]

1.1 Problem StatementPeople are now mobile than ever before and require their I.T. applicaons and data tobe ubiquitous and device independent. Cloud is the answer to this, but if you have

condenal data that cant be uploaded in public domain and over the third party

data centres, Private Cloud on the organizaons resources is the soluon.

1.2 Objecves1. Design Private Cloud storage.

2. Integrate it with the UET, Taxilas servers.

3. Create users roaming prole so that they can access data from anywhere and fromany device.

4. System is fully scalable if demand increases.

1.3 BackgroundCloud compung is an evolving paradigm. The NIST is the internaonal body for the

standards in technology. The NIST denion of cloud characterizes important aspects

of cloud compung and is intended to serve as a means for broad comparisons of


11/34

[11]

cloud services and deployment strategies, and to provide a baseline for discussion

from what is cloud compung to how to best use cloud compung.

Cloud compung is a model for enabling ubiquitous, convenient, on-demand network

access to a shared pool of congurable compung resources e.g., networks, servers,

storage, applicaons, and services) that can be rapidly provisioned and released with

minimal management eort or service provider interacon. This cloud model is

composed of ve essenal characteriscs, three service models, and four deployment

models. [2]

1.3.1 Characteriscs of Cloud

On-demand self-service.A consumer can unilaterally provision compung capabilies, such as server meand network storage, as needed automacally without requiring human interacon

with each service provider.

Broad network access.Capabilies are available over the network and accessed through standard

mechanisms that promote use by heterogeneous thin or thick client plaorms (e.g.,

mobile phones, tablets, laptops, and workstaons).

Resource pooling.The providers compung resources are pooled to serve mulple consumers using a

mul-tenant model, with dierent physical and virtual resources dynamically

assigned and reassigned according to consumer demand. There is a sense of locaon

independence in that the customer generally has no control or knowledge over the

exact locaon of the provided resources but may be able to specify locaon at a

higher level of abstracon (e.g., country, state, or datacentre). Examples of resources

include storage, processing, memory, and network bandwidth.

Rapid elascity.Capabilies can be elascally provisioned and released, in some cases automacally,to scale rapidly outward and inward commensurate with demand. To the consumer,

the capabilies available for provisioning oen appear to be unlimited and can be

appropriated in any quanty at any me.

Measured service.

Cloud systems automacally control and opmize resource use by leveraging a

metering capability1 at some level of abstracon appropriate to the type of service

(e.g., storage, processing, bandwidth, and acve user accounts).


12/34

[12]

1.3.2 Service Models

Soware as a Service (SaaS).The capability provided to the consumer is to use the providers applicaons running

on a cloud infrastructure2. The applicaons are accessible from various client devices

through either a thin client interface, such as a web browser (e.g., web-based email),

or a program interface. The consumer does not manage or control the underlying

cloud infrastructure including network, servers, operang systems, storage, or even

individual applicaon capabilies, with the possible excepon of limited user-specic

applicaon conguraon sengs.

Plaorm as a Service (PaaS).The capability provided to the consumer is to deploy onto the cloud infrastructure

consumer-created or acquired applicaons created using programming languages,libraries, services, and tools supported by the provider.3 The consumer does not

manage or control the underlying cloud infrastructure including network, servers,

operang systems, or storage, but has control over the deployed applicaons and

possibly conguraon sengs for the applicaon-hosng environment.

Infrastructure as a Service (IaaS).The capability provided to the consumer is to provision processing, storage,

networks, and other fundamental compung resources where the consumer is able

to deploy and run arbitrary soware, which can include operang systems and

applicaons. The consumer does not manage or control the underlying cloud

infrastructure but has control over operang systems, storage, and deployed

applicaons; and possibly limited control of select networking components (e.g., host

rewalls).

Figure 1-Service Models and Apps


13/34

[13]

1.3.3 Deployment Models

Private cloud.The cloud infrastructure is provisioned for exclusive use by a single organizaon

comprising mulple consumers (e.g., business units). It may be owned, managed,

and operated by the organizaon, a third party, or some combinaon of them, and it

may exist on or o premises.

Community cloud.The cloud infrastructure is provisioned for exclusive use by a specic community of

consumers from organizaons that have shared concerns (e.g., mission, security

requirements, policy, and compliance consideraons). It may be owned, managed,

and operated by one or more of the organizaons in the community, a third party, or

some combinaon of them, and it may exist on or o premises.

Public cloud.The cloud infrastructure is provisioned for open use by the general public. It may be

owned, managed, and operated by a business, academic, or government

organizaon, or some combinaon of them. It exists on the premises of the cloud

provider.

Hybrid cloud.The cloud infrastructure is a composion of two or more disnct cloud

infrastructures (private, community, or public) that remain unique enes, but are

bound together by standardized or proprietary technology that enables data and

applicaon portability (e.g., cloud bursng for load balancing between clouds).

Figure 2-Private Cloud


14/34

[14]

Figure 3-Public Cloud

1.4 Our Model:We are developing Private cloud as a deployment model and providing Infrastructure

as a Service (IaaS). Our client, HEC, is a research organizaon, which has an

infrastructure need at most.

Advantages of Private Cloud:1. Highly secure due on on-premise setup.2. Service exibility according to the organizaons need.3. Long term cost eecveness. [3]

1.5 DeliverablesCloud based Storage, incorporang total standard funconality and usability, based

on commercially available applicaons, which serve as private ubiquitous storage for

PERN & the HEC network in Pakistan.

1.6 Tools Used Microso Visual Studio JavaScript SDK VMware ESXi Hypervisor

VMware Vsphere


15/34

[15]

1.7 Organizaon of ThesisIn First Chapter the introducon of the project is given and background is discussed.

Second chapter presents the literature review about the Cloud Technology, its

working principle, case studies, and windows explorer applicaons for usability server

implementaon.

Third chapter relates to the methodology that will be adopted for the compleon of

the project.

In the fourth chapter the programming and simulaons of project in Microso Visual

studio and Server implementaon are given.


16/34

[16]

CHAPTER 2: LITERATURE REVIEWCloud Compung is in fashion. But what is it? Is it justthe same thing as outsourcing

the hosng of Web applicaons? How does it change the future of enterprise

architectures? How might clouds form the backbone of twenty-rst-century

ecosystems, virtual organizaons and, for a parcular example, healthcare systems

that are truly open, scalable, heterogeneous and capable of supporng the players/

providers both big and small?In the past, IT architectures took aim at the enterprise

as their endpoint. Perhaps now we must radically raise the bar by implemenng

architectures capable of supporng enre ecosystems and, in so doing, enable these

architectures to scale both downward to enterprise architecture as well as upward

and outward. [4]

Cloud compung oerings today are suitable to host enterprise architectures. But

while these oerings provide clear benet to corporaons by providing capabilies

complementary to what they have, the fact that they can help to elascally scale

enterprise architectures should not be understood to also mean that simply scaling in

this way will meet twenty-rst-century compung requirements. [5]

An autonomic approach permits us to idenfy core components of an autonomic

compung architecture that Cloud Compung instanaons thus far placed lile

emphasis on. We idenfy technical characteriscs below that must not be overlookedin future architectures:

An architecture style (or styles) that should be used when implemenngcloud-based services

External user and access control management that enables roles and relatedresponsibilies that serve as interface denions that control access to and

orchestrate across business funconality

An Interacon Container that encapsulates the infrastructure services andpolicy management necessary to provision interacons

An externalized policy management engine that ensures that interaconsconform to regulatory, business partner, and infrastructure policy constraints

Ulity Compung capabilies necessary to manage and scale cloud orientedplaorms


17/34

[17]

2.1 An Autonomic Frame of MindThe architectures that we deploy in data centers today should be able to run in a

cloud, simply moving them into a cloud stops well short of what one might hope thatCloud Compung will come to mean. [6]In fact, tackling global-scaled collaboraon

and trading partner network problems in government, military, scienc, and

business contexts will require more than what current architectures can readily

support. For example:

It will be necessary to rapidly set up a temporary collaboraon networkenabling network members to securely interact online, where interacon

could imply interoperability with back oce systems as well as human

oriented exchanges all in a maer of hours.

Business interacons have the potenal to become more complex thanpersonal transacons.

The way that users and access control are managed in typical applicaonstoday is no longer exible enough to express roles and responsibilies that

people will play in next-generaon business interacons.

2.2 Features of CloudThe above menoned consideraons suggest that cloud will have to have at leastthefollowing characteriscs:

Clouds should be uniquely idenable so that they can be individuallymanaged even when combined with other clouds. This will be necessary to

disnguish and harmonize cloud business and infrastructure policies in force.

A cloud should be dynamically congurable: conguraon should beautomatable in varying and unpredictable, possibly even event-driven,

condions.

Systems management technologies for clouds must integrate constraints onbusiness with constraints on infrastructure to make them manageable in

aggregate.

- A cloud should be able to dynamically provision itself and opmize itsown construcon and resource consumpon over me.

- A cloud must be able to recover from roune and extraordinary eventsthat might cause some or all of its parts to malfuncon.


18/34

[18]

- A cloud must be aware of the contexts in which it is used so that cloudcontents can behave accordingly.

A cloud must be secure, and it must be able to secure itself.

These coarse-grained characteriscs, somemes described as autonomic compung,

can be represented in the form of ner-grained architecture drivers that are useful in

characterizing steps toward an autonomic compung architecture. [7] Cloud

Compung oerings that are available today share many of the same drivers that we

have organized into Systems and Applicaon Management Drivers in the gure

below. Numbered circles in the graphic above denote drivers that are listed below:

Figure 4-Cloud Drivers

0. Architecture state: no systems management1. Systems and resources must be idenable2. System and resources must be manageable3.

Policy

-

driven secured access to the system and managed resources must beprovided


19/34

[19]

4. System must reallocate managed resources on failures as a funcon of policy5. System must reallocate managed resources on various system-level condions

by policy

6.

System must be managed lights-

out in a single data center context

7. Systems management capability must scale across clouds of the same type8. Systems management capability must scale across clouds of dierent types;

these clouds must be managed uniformly while maintaining separate cloud

idenes

9. System must reallocate managed resources on various system-level condionsas a funcon of policy to accommodate real-me and business-oriented usage

paerns

10.Systems management policies are harmonized across cloud boundaries11.It must be possible to integrate management policies of dierent clouds12.Monolithic applicaons and tradional applicaon integraons exist/are

sucient

13.Applicaon plaorm must be service oriented [8]14.Applicaons are replaced with business services15.Business services have secured access16.An Interacon Container1 must be used as applicaon container in a single -

tenant environment

17.Policies must be consolidated and managed using a single (possibly federated)policy engine

18.System must reallocate managed business services on various business levelcondions by policy to accommodate real-me/batch usage paerns

19.An Interacon Container must be used as applicaon container in amultenant environment

20.Business service and systems management policies are integrated21.Architecture state: posioned as an autonomic architecture plaorm for

virtual organizaon-oriented applicaon systems

22.Architecture state: addional structural and business constraints posioningarchitecture plaorm as a service grid


20/34

[20]

The graph depicts two paths toward autonomic compung that ulmately converge

at an architecture point that could support business ecosystems and emergent and

uid virtual organizaons:

The rst path, Systems Management Drivers, begins with no systems management,

and ends with a systems management capability that is policy driven, and that

enables automated systems management in a cloud and harmonizaon of business

and infrastructure policies within and across cloud boundaries in both single- and

mul-tenant modes. The drivers for systems management are grouped to illustrate

needs common to basic systems management (Systems Management Capabilies),

and needs that go beyond the basic capabilies (Ulity Compung Management and

Outside-In Architectureiii Capabilies). [9]

The second path,Applicaons Management Drivers, begins with common monolithic

corporate applicaons. It ends with these applicaons having been replaced with aservice-oriented ones, where policy has been externalized so that business policies

can be harmonized with ulity management policies, where it is possible to

implement end-to-end service level agreements and enforce conformance to

business and regulatory constraints, and where the use of business funconal and

infrastructural components can be metered and elascally load balanced. At this

endpoint, business services and infrastructure can be organized into a cloud and used

in both single- and multenant modes. [10]

2.3 Characteriscs of an autonomic service architectureAs cloud compung soluons and products are implemented, we believe it crical

especially to those being driven by their business needs up the Systems and

Applicaons Management Drivers curves [11] to carefully consider their need for

support of the architecture characteriscs elaborated ass below:

2.3.1 Architecture styleArchitecture styles dene families of soware systems in terms of paerns for

characterizing how architecture components interact. They dene what types of

architecture components can exist in architectures of those styles, and constraints on

how they may be combined. They dene how components may be combined

together for deployment. They dene how units of work are managed, e.g., whether

or not they are transaconal (n-phase commit). And they dene how funconality

that components provision may be composed into higher order funconality and

how such can be exposed for use by human beings or other systems. [12]

The Outside-In architectural style is inherently top-down and emphasizes

decomposion to the funconal level, but not lower; is service-oriented rather than


21/34

[21]

applicaon-oriented; factors out policy as a rst class architecture component that

can be used to govern transparent performance of service -related tasks; and

emphasizes the ability to adapt performance to user/business needs without having

to consider the intricacies of architecture workings.

The counter style, what we call inside-out, is inherently boom-up and takes much

more of an infrastructural point of view as a starng point, building up to a business

funconal layer. Applicaon plaorms constructed using client server, object-

oriented, and 2/3/n-er architecture styles are those to which we apply the

generalizaon inside-out because they form the basis of enterprise applicaon

architectures today, and because architectures of these types have limitaons that

require transformaon to scale in a massive way vis--vis outside-in plaorms.

Implementaon of an outside-in architecture results in beer architecture layering

and factoring, and interfaces that become more business than data oriented. [13]

2.3.2 External user and access control managementUser and access control management usually is implemented within a typical

enterprise applicaon. A user is assigned one too many applicaon roles, and a role

names a set of privileges that correlate to use of parcular applicaon funconality

through a graphical user interface, or through some programming interface. User

authencaon and authorizaon can be integrated with corporate identy

management soluons (e.g., single sign-on soluons) that are in place to ensure that

only people within a corporaon or corporate partner network are permied to usecorporate applicaons. [14]

A fundamental part of user management is identy management. There are

numerous identy soluons available today from vendors like Microso, Sun

Microsystems, and Oracle. The challenges facing these soluon vendors include their

ability to manage the varied ways a user can be represented in an online context, the

means to verify identy and detect and manage identy the, the need to

accommodate audits of transacons and interacons conducted with a specic

identy, and so forth. Identy Management is much larger than any single cloud orsoware vendor, and forming a soluon for the twenty-rst-century is even likely to

require help from naonal governments. [15]

2.3.3 Interacon containerThe J2EE/Java EE community introduced the noon of container to the enterprise

architecture community as a means to streamline the structure of thin java clients.

Normally, thin-client muler applicaons would require code to implement

persistence, security, transacon management, resource pool management,

directory, remote object networking, and object life cycle management services. TheJ2EE architecture introduced a containermodel that made this funconality available


22/34

[22]

transparently, in many cases to business logic implemented as classes of

behavior as long as it was implemented to conform to special (e.g., bean) interfaces,

freeing developers to focus on implemenng business funconality and not

infrastructure resulng in a standardized use of infrastructure services. Containers

are hosted in applicaon servers.

The term Interacon Container is used as an analog to J2EE/Java EE applicaon

container. The Interacon Container is hosted in an Interacon Server, stacally and

dynamically congured to provide infrastructure and policy adjudicaon services that

are specic to a business users environment, integrated with systems management

capabilies, and used to manage one-to-many Interacons and their life cycles. An

Interacon Container essenally holds an execuon context in which role players

people or systems parcipang in an Interacon and conforming to specic roles

(interfaces) interact to perform their parts in a business orchestraon and manageexcepons and/or faults should they occur in the process.

An Interacon Containercan be considered to be organized based (i.e., it can be used

to manage many Interacons between a set of parcipants/role players over me),

or outcome-based (in which only one Interacon would be performed). These two

usage scenarios reect the need to manage Interacons in a dynamic user

community, where role players could change over me, and the need to manage an

Interacon as a single possible long-running business transacon.

2.3.4 Externalized policy management/policy EngineA Policy Engine harmonizes and adjudicates conicng policies used across

architecture layers. Components at all architecture layers can parcipate in policy

harmonizaon and enforcement, which requires the following:

Policy extension points must be exposed and formally declared in any part ofthe architecture that must be managed.

Policy management must support policy pushdown to enable extensible anddynamic detecon of policy violaon and policy enforcement.

It must be possible to version policy so that policy decisions made at a givenme can be reproduced.

Policy embedded in applicaon funconality is not easy to change, but future

soware systems will have to be implemented in a way that views change as the

norm where change results from the emergence of new markets, market

evoluon, changes in regulaons and standards, xing of policy bugs, the whims of

interacon parcipants, and may be even their customers whims. [16]


23/34

[23]

2.3.5 Ulity CompungAs systems become more interconnected and diverse, architects are less able to

ancipate and design interacons among components, leaving such issues to be dealt

with at runme. Soon systems will become too massive and complex for even the

most skilled system integrators to install, congure, opmize, maintain, and merge.And there will be no way to make mely, decisive responses to the rapid stream of

changing and conicng demands.

An autonomic compung architecture calls for architecture components to,

themselves, be autonomic. This might sound a bit far-fetched unless we consider that

we have been solving heterogeneity problems with abstracon layers at the

operang system layer for some years now, and that this technique can be used again

to manage large collecons of compung resources uniformly. In parcular, if two

clouds are autonomic and essenally support the same management interfaces, thenthey could be composited into a larger cloud while preserving the idenes of the

original clouds. Intuively, this simplies scaling clouds and reconciling policy

dierences. [17]


24/34

[24]

CHAPTER 3: METHODOLOGY

In this chapter we will give claricaon about the method that is used in our project.

It includes the enre project plan, explanaon of the design ow and also design

architecture.

3.1 PLANThis secon includes the whole project plan, its basic architecture, its working

methodology and architectures of dierent parts like sensor node, gateway node and

control room equipment.

We are basically using the Self-Service IT portal for the cloud. We are dealing withfollowing:

3.1.1 Cloud Infrastructure Soware:One of the major components of any private cloud implementaon (be it standalone

or part of a hybrid cloud (soluon) is the soware that provides access to the

underlying physical resources. This soware provides orchestraon controls for the

deployment of the virtual machines, storage oerings, and network conguraons

that are leveraged by the workloads of the private cloud. The product category for

the vendors of these soluons is known by various names, the most prevalent being

cloud infrastructure soware. [18]

There are many opons for cloud infrastructure soware, commercial like VMware &

Microso Azure and open source like Open Stack but we are using the same

architecture on which PERN cloud previously exists.

3.1.2 Cloud management server/cloud controller:The end user accesses the cloud resources via an API call that is processed by the API

endpoint. This API endpoint funcons as the cloud controller. It also coordinates theallocaon of private cloud resources based on the API command executed. Each

compute node of the resource pool has local storage, which can be either true local

storage that is physically aached to the node, or that is accessed via a shared pool of

storage over NFS, iSCSI, Fibre Channel, or similar mechanisms.

Each of the compute nodes host one or more VMs; with the underlying hypervisor

managing access to the nodes resources by each of the resident VMs (bare-metal

conguraons without a hypervisor are also possible with some cloud infrastructure

soware oerings).


25/34

[25]

The architecture shown in Figure can be expanded to include mulple clusters that

add both capacies to the soluon as well as redundancy that can be used to

increase the overall availability of the infrastructure.

The foremost task of this project is to create Server Templates.

Server Templates (a conguraon

blueprint for a server running on a cloud)

and made these templates accessible to the

business units end users. The end users

logged in to the Dashboard of the cloud

interface and selected one of these

precongured Server Templates. In a maer

of minutes, they provisioned a fully

congured and available server for their

test and development purposes. Because

each of these server instances was

independent, an end user could perform

whatever acons he needed without being

concerned about modifying the

environment of another end user. When

development and tesng was completed,

the end user terminated the server

instance, which reduced operaonal costs

and freed up resources that could be

repurposed for another user.

3.2 Client End ApplicaonThe applicaon is JavaScript and html based. It accesses the SkyDrive architecture of

Microso through its API. The applicaon acts the the interface between the user

computer and the database cloud storage. Applicaon is integrated with the users

windows prole via shell namespace extension. This is done through windows ATLlibraries.

3.2.1 ATL:The Acve Template Library (ATL) is a set of template-based C++ classes developed by

Microso, intended to simplify the programming of Component Object Model (COM)

objects. The COM support in Microso Visual C++ allows developers to create a

variety of COM objects, OLE Automaon servers, and AcveX controls. ATL includes

an object wizard that sets up primary structure of the objects very quickly with a

minimum of hand coding. On the COM client side ATL provides smart pointers that

deal with COM reference counng.

Figure 5-Cloud Controller


26/34

[26]

3.3 Server Side Implementaon3.3.1 HypervisorIn compung, a hypervisor or virtual machine monitor

(VMM) is a piece of computer soware, rmware or

hardware that creates and runs virtual machines. A

computer on which a hypervisor is running one or more

virtual machines is dened as a host machine. Each

virtual machine is called a guest machine. The

hypervisor presents the guest operang systems with a

virtual operang plaorm and manages the execuon

of the guest operang systems. Mulple instances of a

variety of operang systems may share the virtualized

hardware resources. [19]

It is a type 1 or bare metal virtualizaon model.

3.3.2 Hypervisor ServerThe system we have adopted is the type-1 hypervisor. The hypervisor is installed on

the server. The hypervisor we used is the VMware ESxi hypervisor. It has all the

resources i-e: storage, cache and memory. The hypervisor running server will

encompass various instances on which the user applicaons can run. The instances

can be of many types; Windows, Linux Ubuntu, Fedora or LAMP server. The

hypervisor running machine, the server has the IP address by which it is accessed on

the network and the instances running on the sever has its separate IP addresses

obviously dierent from the server IP address. The hypervisor installed server doesnt

have much of the informaon to show or help. It even has the interface and

programs to control the instances and the operaon ability of the server. These tasks

related to servers are performed by the management soware in the remote locaon

or machine. In our case, its VMware Vsphere. [20]

Figure 6-Hypervisor Type-1


27/34

[27]

3.3.3 Management sowareThe control and maintenance unit of the hypervisor server is the management

soware, which is at the remote locaon and is connected to the server through the

network using the IP address of the server. The management soware is simply the

dashboard to the server. Current condion of the server, how many instances arerunning and much resources are currently ulizing, of the whole server as well as an

individual instances all is shown in the management soware. You can allot resources

of the hypervisor server to the user through it. [19]

Figure 7-VSpehere Implementaon Model

3.4 Client-Server InterfacingThe cloud based applicaon model we have followed is the web 2.0.

3.4.1 Web 2.0Web 2.0 describes web sites that use technology beyond the stac pages of earlier

web sites. Web 2.0 websites allow users to do more than just retrieve informaon. By

increasing what was already possible in "Web 1.0", they provide the user with a more

user - interface, soware and storage facilies, all through their browser. This has

been called "network as plaorm" compung. Some scholars have put forth cloud

compung as an example of Web 2.0 because cloud compung is simply an

implicaon of compung on the Internet. [22]


28/34

[28]

The key features of Web 2.0 include:

1. Folksonomy; free classicaon of informaon2. A rich user experience3. A user as a contributor4. Long tail5. User parcipaon6. Basic trust7. Dispersion

The client-side (web browser) technologies used in Web 2.0 development include

Ajax and JavaScript framework. The data fetched by an Ajax request is typically

formaed in XML or JSON (JavaScript Object Notaon) format; two widely used

structured data formats. Since both of these formats are navely understood by

JavaScript, a programmer can easily use them to transmit structured data in their

web applicaon. For example, Google Docs uses this technique to create a Web

based word processor.

Web 2.0 can be described in three parts:

Rich Internet applicaon (RIA) denes the experience brought fromdesktop to browser whether it is from a graphical point of view or usability

point of view. Some buzzwords related to RIA are Ajax and Flash.

Web-oriented architecture (WOA) is a key piece in Web 2.0, which deneshow Web 2.0 applicaons expose their funconality so that other applicaons

can leverage and integrate the funconality providing a set of much richer

applicaons. Examples are fed, RSS, Web Services, mash-ups.

Social Web denes how Web 2.0 tends to interact much more with the enduser and make the end-user an integral part.

Using web 2.0 technology enables us to incorporate REST architecture. In fact, this

client/server relaonship is a prerequisite of a set of principles called REST (or

Representaonal State Transfer).

3.4.2 REST:Representaonal state transfer (REST) is a style of soware architecture for

distributed systems such as the World Wide Web. REST has emerged as a

predominant web API design model.

Key goals of REST include:

Scalability of component interacons Generality of interfaces Independent deployment of components


29/34

[29]

3.4.2.1 RESTful APIAn API, or applicaon programming interface, is kind of like a coding contract: it

species the ways a program can interact with an applicaon. For example, if you

want to write a program that reads and analyses data from Twier, you'd need to use

the Twier API, which would specify the process for authencaon, important URLs,classes, methods, and so on. [20]

For an API or web service to be RESTful, it must do the following:

1. Separate the client from the server2. Not hold state between requests (meaning that all the informaon necessary

to respond to a request is available in each individual request; no data, or

state, is held by the server from request to request)

3. Use HTTP and HTTP methods

3.5 Flow of DesignAccording to our requisite, we divide the design into two parts:

1) Applicaon Development

2) Applicaon Deployment

3.5.1 Applicaon Development

Figure 8- Applicaon Development Flow


30/34

[30]

3.5.2 Applicaon Deployment

Figure 9- Applicaon Deployment Flow


31/34

[31]

CONCLUSION

The project is based on the development of a private cloud ensuring SkyDrive like

services. It allocates user's congurable compung resources that are ubiquitous and

scalable. This is done through a client-side applicaon integrated with windows

explorer through roaming user proles. The applicaon is a service independent due

to its web 2.0 and REST architecture. Its RESTful API can be linked to various cloud

services.


32/34

[32]

FUTURE WORK

To deploy the prototype of a cloud storage system at naonal level, on PERN

architecture. This will create a huge breakthrough in educaon research in Pakistan.


33/34

[33]

REFRENCES

[1] A. F. R. G. Michael Armbrust, "Above the Clouds: A Berkeley View of Cloud,"

Electrical Engineering and Computer Sciences, 2009.

[2] Naonal Instute of Standards and Technology, "NIST Cloud Compung

Reference Architecture," NIST, 2011.

[3] Arista, "Cloud Storage Whitepaper," www.aristanetworks.com.

[4] Ericsson, "Operator opportunies in cloud service delivery," 2012.

[5] Delloite, "Cloud compung: A collecon of working papers," 2009.

[6] tango telecom, "ENABLING EXTREME COMPETITION," 2012.

[7] P. A. A. P. C. Bengt Ahlgren, "Content, Connecvity, and Cloud: Ingredients for the

Network of the Future," p. 22.

[8] M. K. Vishal Jain, "Informaon Retrieval through Mul-Agent System with Data

Mining in Cloud Compung," IJCTA, p. 5, 2012.

[9] E. D. Gbor Fodor, "Design Aspects of Network Assisted Design Aspects of

Network Assisted," IEEE communicaon magazine, p. 8, 2012 .

[10] Verivue, "Designing a Cloud Storage System," www.verivue.com/object-store.

[11] K. Ferguson-Boucher, "Cloud Compung: A Records and Informaon

Management Perspecve," IEEE security and privacy, 2011.

[12] IDC, "Mobile Virtualizaon: Accelerang Innovaon in Next-Generaon

Services," 2012.

[13] M. Alendal, "The premium cloud: How Operators can maximize prot".

[14] Ericsson, "Enabling the network-embedded cloud," 2012.

[15] A. K.-H. Ilango Sriram, "Research Agenda in Cloud Technologies".

[16] Ericsson Review, "Transport networks in the Cloud Age," 2012.

[17] Ericsson, "Deploying telecom-grade Cloud," 2012.


34/34

[18] R. Brian Adler, "Designing Private and Hybrid Clouds," 2012.

[19] R. Vanover, "Virtualizaon review," [Online]. Available:

hp://virtualizaonreview.com/blogs/everyday-virtualizaon/2009/06/type-1-

and-

type-

2-

hypervisors-

explained.aspx. [Accessed 04 01 2013].

[20] VMware, "VMware Infrastructure 3," 2006.

[21] VMware, "VMware vSphere 5 Compeve Reviewers Guide," [Online].

Available: hp://www.vmware.com/les/pdf/VMware-vSphere-Compeve-

Reviewers-guide-WP-EN.pdf. [Accessed 02 07 2013].

[22] Microso, "ATL refrence," [Online]. Available: hp://msdn.microso.com/en-

us/library/t9adwcde%28v=vs.80%29.aspx. [Accessed 2 7 2013].

[23] Microso, "Skydrive API," [Online]. Available: hp://msdn.microso.com/en-

US/library/live/hh826521. [Accessed 02 07 2013].

Documents

Cloud based Storage