TermPaper

CECS 526
Term Paper Assignment
ANAND CHOKSHI (013642640)
VIRAL SAVANI (013647918)
Major Design Issues in Cloud Computing OS
And their Mitigation Techniques
1. Abstract
Traditionally Cloud Computing is used by organizations to increase computational performance
and IT resource flexibility by using remote servers connected through efficient network
consequently reducing the cost of purchasing the physical hardware and its maintenance.
Currently, companies employing cloud computing requires to adopt the approach of Hybrid Cloud
[1], where Public Cloud Deployment Model is used to perform work which require heavy
computation and Private Cloud Deployment Model is used when data sensitivity is center of
emphasis. This distinction and switching between deployment models must occur seamlessly and
without any consumer’s (who uses cloud services) intervention, implying there must be some
abstraction provided which can support and merge this deployment models intelligently so they
can work/appear as single system from consumer’s and administrator’s perspective. Currently
above mentioned abstraction is provided by middleboxes [2]: a hardware based network appliance,
which suffers from problems such as: expensive to buy and manage, new feature essentially
implies new piece of hardware and finally cannot be scaled respective to consumer’s fluctuating
demand. In short, a paradigm shift is needed from hardware to software, which can be sufficed by
Operating System (OS) supporting Cloud Computing. To perform this shift massive amount of
task which were previously performed by hardware needs to be done by OS which introduces
design issues. To start with: It should provide services (API’s) in bountiful to application so that
it transfers the load of formulating significant functions for scheduling, power management, virtual
machine monitoring and memory management from application to OS. Secondly, Security and
Consistency which ensures the authorized access of assert (that can data or resource) and logical
coherence of a system respectively. In addition to these, it should also be able to bifurcate and
understand different type of workload and device a plan which stabilize and optimize these
workload. [3] Scalability: dynamic provisioning of resources, Non-static demand of resources: if
consumer A performs 200GigaFLOPS of works there is no certainty that he/she will demand exact
amount of work subsequent time, Fault-tolerance: to perform desired function in an event of failure
of some components, system’s global view, OS updates and user management are issues if not
addressed in efficient manner may/certainly lead to demoralizing performance or in worst case
result into total system failure. This paper indents to lay in-depth focus on the various design issues
of OS supporting cloud computing and various techniques to mitigates this issues.

Major Design Issue in Cloud OS And their Mitigation Techniques
2 | P a g e
2. Abstract Interface/ APIs
Cloud is a heterogeneous environment where different hardware interact with different software
on regular basis. Major challenge faced by cloud OS would be to design set of APIs or abstract
interface which would address the issues of interoperability between various hardware and
software architecture at the same time providing the most fundamental and essential functionalities
which aids programmers in focusing major aspects of coding software while transferring the load
of house-keeping tasks such as memory management, kernel-level security, scheduling, and many
more. from programmer to APIs. Building APIs on open standard will result in creating a flexible
environment where organization can avoid lock-in or vendor check-out which are very frequent
problem with proprietary APIs. Also, open standards will allow free flow of data and workload
between clouds with diverse low-level (machine level) implementation. Using open standards will
implicitly result in reusability. [1] “Hard coding applications to fit specific business and cloud
technology requirements would tend to slow down the process and make it hard for developers to
achieve the level of reusability needed.” Hard-coding an application inherently suffers from
problem such as code-modification/update may lead to ripple effect and if not rectified correctly
may cripple entire application. Designing APIs and interfaces following open-standard paradigm
may essentially give costumers/users/programmers of application a way to alter any hardware level
changes as interoperability between different vendors is provided by open standard. It is important
to understand that different user may focus more on specific interface, such as end-users will select
service which provides efficient Look and Feel: user interface while software developers may
focus on APIs provided by platform. Chain of service [4], is established when a service from
different layer is coupled with service in other or successive layers. Think of it as a vendors builds
a service/API for PaaS (Platform as a Service) which is built on (coupled with) service in IaaS
(Infrastructure as a Service), pros and cons: improvement in a service may directly/indirectly
improve performance of service it is coupled with or else base service may impose basic restriction
on the service implemented above it i.e. a case may arise that service in PaaS is simply not
achievable due to restriction laid by IaaS. To remove or reduce such kind of coupling developers
should follow the functional design hypothesis where one module is only responsible for a function
avoiding/minimizing any side-effects. OpenStack is a widely used for IaaS solution and is the best
example for using open standards for implementing cloud services.
2.1 Different User, Different Interface
Table 2.1 from [4] shows the different need of user at different levels of services. The
services provided at IaaS level mainly focus on how cloud operations are created, initiated,
installed and terminated. PaaS is the link between IaaS and SaaS, it kind of provides a way
to use the functionality provided by hardware without understanding the complex
fundamental architecture. Lastly SaaS, where software which provides the functionality
supported by underlying layers to user in form of service. This is the most dynamic layer
as different user have different preference for document format and data files. For user at
any given level it is highly possible that they do not know about the functionality provided
to user at different level, resulting each user has his own set of functions and scope within
which he works. Cloud OS needs to work as mediator between each of this
abstractions/interfaces and provide a complete “Good” model which coherently works in
dynamic environment. For example consider a case where programmer at PaaS level has
spent huge effort to add different functionality in software which is used by user at SaaS

3 | P a g e
level. Now if appropriate changes are not made in user interface at SaaS level then those
functionality cannot be utilized efficiently or in worst case user at SaaS has no knowledge
of such added functions. Problems such as programmer has no knowledge of underlying
hardware, thus it is responsibility of Cloud OS to solve any ambiguity between
programmed software and hardware architecture.
[Table 2.1 Cloud Architecture Type and Interfaces [4]]
3. Security Issues
By definition cloud computing is a collection of remote machines and technologies, so any security
issue in those machines or technologies are inherently passed to cloud OS implementing cloud.
For example the network through which data is transferred should be secured and the distributed
transaction involving database should be atomic. In addition to these, security issues related to OS
which are exacerbated due to wide scope and dynamic environment are to be addressed now. There
are user involved at different levels which implies each set of user is to be protected by certain
type of security which differs from level to level. Table 3.1 [5], represents security requirements
and threats involved with each of them. Security is a wide issue which encompasses following
topics:
3.1 Trust
‘‘An entity A is considered to trust another entity B when entity A believes that entity B
will behave exactly as expected and required’’ [6]. In traditional approach any connection

4 | P a g e
[Table 3.1 User Specific Security Requirement [5]]
to organization or workplace situated outside of a system is an potential opening for
unauthorized access. In static environment trust between systems can be enforced by
security policies manually but in cloud this techniques is not feasible as connection are
dynamic and sometime even user does not possess the knowledge of every connection
made to outside organization. Trusted Third Party (TTP) [5], where data integrity and
authorization are enable using cryptography. TTP acknowledges to provide trusted and
secure services which are scalable at the same time minimizes risk factor.
3.2 Confidentiality and Privacy
Confidentiality implies that only trusted parties or authorized systems are allowed to gain
access of protected data. Multitenancy (resource sharing) plays main role in cloud
computing. OS implementing cloud computing have to satisfy multitenancy as well as
confidentiality. Multitenancy may accidentally breach data confidentiality due to data
remanence: Residual data that remains even after attempts have been made to erase or
delete data. Cloud OS must design security policy which at best allows multitenancy and
no confidentiality conflicts and at worst allows limited multitenancy with no confidentiality

5 | P a g e
breach (data sensitive systems) or high multitenancy and limited confidentiality (high
performance system). Privacy is more intimately involved with user than confidentiality.
In cloud OS data stored is distributed over numerous location, privacy policy needs to be
coherent at all this location so unauthorized access is not provided to private data. It is duty
of OS to provide and enforce such policy.
3.3 Data and Software Integrity
Data integrity implies the truthfulness of the data, i.e. is the data accessed by user is
authenticate, is that data protected against unauthorized access or alteration or fabrication?
If the answer is “yes” then data integrity is satisfactorily playing its role. Software integrity
refers to protection against unauthorized or out of scope access of resource or data by
software, alteration and data thefts done by software.
Trusted Third Party (TTP), can be used by cloud OS to support above mentioned issues such as
trust, confidentiality, data integrity and data privacy. As described by Castell, ‘‘A Trusted Third
Party is an impartial organization delivering business confidence, through commercial and
technical security features, to an electronic transaction. It supplies technically and legally reliable
means of carrying out, facilitating, producing independent evidence about and/or arbitrating on an
electronic transaction. Its services are provided and underwritten by technical, legal, financial
and/or structural means’’ [7]. Secure data transmission over network is not complex task; however
to protect it from modification or even worse fabrication is intricate. TTPs are usually connected
through certified paths resulting in formation of secure and trusted Public Key Infrastructure (PKI).
PKI can be used to implement IPSec which is service provided by IP layer of TCP/IP model. On
the other hand to run IPSec every machine requires an IPSec client to be present. SSL is other
feature which can be coupled by cloud OS from TCP/IP model to provide end-to-end encryption
by creating encrypted channels between diverse applications. All of the above discussion focuses
on data outside OS but what about data within OS? Answer is Cryptographic Separation [8], aim
here is to conceal the data, process or resources within OS in such a way that it look as if
insubstantial from point of view of unauthorized party.
In [13] an interesting and radical ideas regarding “Novelties in the cloud threat model” [13] are
represented. Firstly, data/information and software are not only the critical data that needs to be
secured, Activity Patterns needs to be protected also. Tracking such patterns may constitute
confidential information. Trust chains (can be compared with service chain described in scalability
issues) where application on SaaS level depends on some service on PaaS which in turn depends
on IaaS service thus each of the service must be “Trusted”.
4. Scalability Issues
Current OS architecture revolves around the usage of multicore where core supported is limited in
terms of quantity. The EULA (End User’s License Agreement) of Windows 7 OS states that “You
may use the software on up to two processors on the licensed computer at one time.” Currently a
single processor can support up-to two digits of core. However, the cloud computing in its most
trivial implementation may lead to cores in multiple of thousand, which is out of scope of OS. In
cloud, common processing system/ processor/CPUs is increasing at revolutionary level, resulting

6 | P a g e
in scalability to be the core importance of designing Cloud OS. Traditional methods such as
vertical scaling (increase the capacity of hardware or software by adding resources) and horizontal
scaling (ability to connect multiple entities to work as single logical system) exists, but suffers
from drawback such as “can only get as big as the size of a server” and cannot be implemented on
the spur of moment respectively.
Approach of Factored OS (FOS) in [9], where entire OS is factored on the basis of services which
result in increase of scalability because each service can run autonomously. Fleet are aftermath of
the factoring of the service that are previously factored. Fleet is level two factoring, it can be
thought of as spatially spread, potentially virtual servers. Here individual server in a fleet runs on
its own core resulting in increment of parallelism, also the issue of locality can be optimized by
decreasing communication cost and data access locality. Inside fleet servers can be added or
removed based on the load. In FOS the main component of OS are implemented on different set
of servers then servers on which Application services are implemented which resolves the issue of
implicitly sharing hardware. Due to factoring method FOS creates the scaling quick as it is easy to
migrate OS services to different fleet or machine with help of transparent message passing APIs.
Concept of Service Replication [10], can also be used by cloud OS to counter scalability problems.
Here idea is to duplicate the currently running service to new server/node resulting in optimal
service load leading to no node being bottlenecked while other node are idle. To handle this
procedure centralized approach is used where one node centrally control every replication and
other node actively sends request to central node. A threshold is decided by administrator which
if surpassed may result to request for replication, this threshold can be changed dynamically using
specific rules or manually by system administrator. An alternate approach is that central node is
given ability to check if node is in need of replication, if so it will notify the node to perform
replication. After receiving the notification from central node, it will contact destination node
where it need to replicate its service. Address of destination node is given by central node. Message
passing occurs between the source and destination nodes, on completion of which destination node
will deploy the same service seamlessly. A successful notification is send to central node which
than updates load balancing structure. Most crucial advantages of this approach is that entire
replication occurs without user/customer’s intervention or knowledge. The constructs used in this
approach are messages and tables (for storing address, load balancing data, and many more.) which
can be easily delivered by cloud OS.
Service Migration [10] is technique of migrating service from one node to other due to reasons
such as node failure, physical resource limitation, software limitation, increase in customer’s need
of QoS (Quality of Assurance), and many more. Firstly a node detects any problems within that
may lead to degradation of service it provides if found the node sends notification message with
the service which it was executing. Central node on receiving this notification immediately
terminates the connection of node from the grid until the problem is resolved. Then central node
finds a node which can execute the received service, new node will deploy the service and on
successful deployment it will sent an notification to central node which will update its load
balancing structure. In this technique, failure or incompetence of single node can be masked with
aid of other nodes. Here the role of central node can be effectively played by cloud OS. Main issue
here is what if the service running previously on faulty node was on the verge of completing its
execution, the migration at that moment will result in loss of computation and in worse case

7 | P a g e
duplication of computation at new node. Cloud OS should provide some means to save
intermediate results so entire computation will not be lost on migration. Check pointing is
technique were we can store intermediate results and perform “Rollback” whenever necessary,
though it increases the overhead related to storage of intermediate states and process related to
check pointing, it can be countered with reduction in computation loss of migrating process. Cloud
OS needs to effectively implement such techniques to avoid user intervention and seamless service
migration.
5. Reliability Issues
Reliability literally means a quality of being dependable, in current context, a property of cloud
OS which provides reliable service even when faults occurs up-to certain level. The metrics for a
reliable service depends upon three main aspects. Consistency of information/data, fault-tolerance
and atomicity.
5.1 Consistency
Consider a simple execution of program where one shared variable is updated by two
threads in non-linear fashion. If there is no synchronization mechanism it is easy to violate
the consistency of shared variable. Consistency problem can arise when the final updated
result of shared variable is not propagated to every participating program in proper manner,
resulting in different programs having different image of same shared variable, thus
inconsistent state. Such state in data-sensitive environment may result in erroneous output.
The above situation are described for traditional OS, now consider (for cloud OS) there
exists numerous sites (programs is traditional OS) with various shared resources (variables,
memory address, physical/logical resources), the task of consistent state/image of
particular resource becomes very demanding at the same time imperative. In addition to
this if the cloud OS maintaining the replica of shared files in case if current copy of file is
damaged or inconsistent or to prevent communication cost (a kind of cache) each of the
replica should be “fresh” i.e. consistent with original/main copy of file. Traditionally there
exists two boundary consistency model: Strong consistency approach and Optimistic
approach, former guarantees consistency but introduces great deal of management and
performance overhead while latter eases the overhead but probability of conflict writes and
staleness of replica is high. Continuous Consistency protocols in [11] can be most suitable
for cloud OS as this model is situated between above described two extremes. [11] Coins
the term ‘conit’ which is used to present consistency of an application in quantifiable
manner. It majorly solves following three consistency problems: First, numeric values: It
captures any inconsistency of numerical type between current state of application and final
state. Second, Staleness existing between replicas: Checks if the existing replica is stale or
not with reference of time difference between current time and latest write performed on
main copy. Finally, Ordering of updates: It analyzes the time difference and order of the
updates applied to resident copy respective to ordering of events on main copy.
5.2 Fault Tolerance
The main goal of cloud OS is to provide customer a unified system image and seamless
and uninterrupted services, which raises the issues of masking the faults occurring at

8 | P a g e
hardware or physical level and software or application level by following minimalistic or
no user/customer intervention. Fault tolerance is responsible for this task. Fault tolerance
is widely categorized in two implementation [12]: Exclusive Fault Tolerance Management
which is absolutely implemented by user or service provider (in our case Cloud OS)
independent of each other and other is Collective Fault Tolerance Management where both
parties implement fault tolerance policy on cooperative basis. Each technique has its trade-
offs such as, fault tolerance policy individually at user level is useful for detecting
application or virtual machine faults but faults at hardware level requires knowledge of
hypervisors (a piece of hardware which creates and host many virtual machines) which is
out of scope of users, fault tolerance policy absolutely at provider level can not only detect
application faults but also can be used to perform fault tolerance at hardware level but
results in very high cost at application level (Check pointing is used at application level
which can result in duplication of processing and loss of computation in case rollback is
used).
5.3 Atomicity
Atomicity implies “All or Nothing” and any atomic transaction should be appear as single
indivisible transaction to outside world. Mostly atomicity is a desirable feature in database
but to maintain data consistency in Cloud OS, atomicity is important. In distributed system
two phase commit protocol is used for satisfying atomicity where first phase consists of
coordinator node (in our case Cloud OS) requesting all participating nodes to perform the
necessary local calculation and vote “yes” in case all the local execution is done else “No”
if local node is not yet ready. Based on votes collected in first phase, in second phase
coordinator decide to commit or abort. This decision is then transmitted to all the nodes
and thus a unified commit or abort is performed. Above discussed protocol can be easily
extended to Cloud OS environment with some basic alterations such as coordinator role is
fixed and given to Cloud OS, implementations of basic constructs and special messages
such as “commit” and “abort”.
5. Workload Characterization
Workload is something that is to be executed by cloud requested by user which result in resource
acquisition such as memory, processor and many more depending upon the type of workload. N
execution of any workload is said to be successful if and only if takes finite amount of time for
completion. Traditionally there will be two main type of workload executed by cloud OS first is
batch mode execution of workload where each task is has no real time priority, other is execution
of workload in real-time priority. Other than this there exists many different characteristics such
as is the workload related to analysis of data or is it high-performance workload where rigorous
amount of processing power is needed or is the workload related to database transactions.
Following are some of the characteristics that cloud OS needs to emphasis while considering
workloads:
Inconsistent Demands: A dedicated VM for demand (workload) that is steady and
anticipated is effective than pay-per-use policy. While latter is good for workload that are

9 | P a g e
not uniform. It is responsibility of cloud OS to differentiate such workloads and provide
optimal solution.
Dependencies: The amount of dependences a workload possess directly affects its
execution time. Cloud OS needs to analyze all dependences before executing the task or at
runtime. The knowledge of dependencies may result in selection of proper migration policy
of respective workload which may reduce the cost of migration and bandwidth and in some
cases may also cause reduction in latency.
Criticality: Differentiating a critical workload from no-critical is significant for proper
functioning of cloud OS. Parameters such as availability, response time, security,
confidentiality can be used in quantifiable manner to check if the workload is critical or
not.
6. Some Miscellaneous Issues
One of the key aspect of Operating System is to evolve and modify according to user demands and
environment or to solve some anomaly. For this, cloud OS needs to be regularly updated. To
perform update in traditional OS is not major issues where in case of cloud OS the environment is
highly unstable and dynamic, thus any modification needs to thoroughly tested. Charging and cost
model, how are customer charged is an issues that needs to be handled sensitively otherwise rivals
may gain advantage. Migration from traditional OS to cloud OS should be made as easy as possible
from the customer’s point of view. Resource pooling and management, which resource to use when
and how many units of those resource are needed needs to be monitored. Some issues which cloud
OS inherits from tradition OS that needs to be solved are efficient scheduling in cloud environment,
deadlock detection and prevention, access to resource exclusively (i.e. mutual exclusion), kernel
level protection, transparency from fundamental architecture, and many more. Issues inherited
from cloud may include elasticity of demand (user can demand resource in any amount), relocation
of maintenance activity from user/customer site to service provider’s site, auto-scaling without
customers intervention to provide best performance at economic price, an efficient persistent data
storage facility,
7. Conclusion
Cloud computing has come to a point in its lifecycle where productivity can be focused assuming
that all the issues that were hindering it from being a full fledge commercial application are
resolved or at least mitigated to a level where user can be provided with benefits of technology
and at the same time providers can earn from it. Same is the case with operating systems, but when
this two concepts intersects a set of radical issues come to existence. This paper has explained
some of those crucial issues with their mitigation techniques and are open for future discussion. In
this paper emphasis is laid on pre-existing issues such as scalability, security, abstract APIs and
many more.

10 | P a g e
References:
1. Judith Hurwitz, President at HURWITZ & ASSOCIATES Marcia Kaufman, COO at
HURWITZ & ASSOCIATES, Role of the Operating System in Cloud Environment.
2. ClickOS and the Art of Network Function Virtualization by Joao Martins, Mohamed Ahmed,
Costin Raiciu, Vladimir Olteanu, Michio Honda, Roberto Bifulco, Felipe Huici NEC Europe
Ltd. University Politehnica of Bucharest.
3. An Operating System for Multicore and Clouds: Mechanisms and Implementation, David
Wentzlaff, Charles Gruenwald III, Nathan Beckmann, Kevin Modzelewski, Adam Belay,
Lamia Youseff, Jason Miller, Anant Agarwal At Computer Science and Artificial Intelligence
Laboratory Massachusetts Institute of Technology Cambridge, MA 02139.
4. Ensuring a Thriving Cloud market: Why interoperability matters for business and government,
ECIS Cloud Computing Standards, Compatibility and Interoperability.
5. Addressing cloud computing security issues, Dimitrios Zissis, Dimitrios Lekkas. Department
of Product and Systems Design Engineering, University of the Aegean, Syros 84100, Greece
6. International Telecommunication Union, X-509 | ISO/IEC 9594-8, the directory: Public-key
and attribute certificate frameworks, ITU, X-Series, 2001.
7. S. Castell, Code of practice and management guidelines for trusted third party services,
INFOSEC Project Report S2101/02, 1993.
8. C.P. Pfleeger, S.L. Pfleeger, Security in Computing, Prentice Hall, 2002.
9. A Unified Operating System for Clouds and Manycore: fos, David Wentzlaff, Charles
Gruenwald III, Nathan Beckmann, Kevin Modzelewski, Adam Belay, Lamia Youseff, Jason
Miller, and Anant Agarwal {wentzlaf, cg3, beckmann, kmod, abelay, lyouseff, jasonm,a
garwal}@csail.mit.edu ,CSAIL, Massachusetts Institute of Technology

11 | P a g e
10. Software Approaches to Assuring High Scalability in Cloud Computing, Jae Yoo Lee ; Soo
Dong Kim , e-Business Engineering (ICEBE), 2010 IEEE 7th International.
11. Design and Evaluation of a Continuous Consistency Model for Replicated Services, Haifeng
Yu Amin Vahdat Computer Science Department Duke University Durham, NC 27708 {yhf,
vahdat}@cs.duke.edu http://www.cs.duke.edu/˜{yhf, vahdat}
12. Approaches to Cloud Computing Fault Tolerance. Alain Tchana, Joseph Fourier University,
LIG Laboratory, Grenoble, France. Email: first.last@inria.fr. Laurent Broto, Daniel Hagimont,
University of Toulouse, IRIT Laboratory, Toulouse, France, Email: first.last@enseeiht.fr
13. What’s New About Cloud Computing Security? Yanpei Chen, Vern Paxson, Randy H. Katz.
Technical Report No. UCB/EECS-2010-5
http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-5.html

TermPaper

More Related Content

What's hot

Viewers also liked

Similar to TermPaper

TermPaper