1.

Security of Database Services (DBaaS)

Security in Database-as-a-Service (DBaaS) is a major concern for cloud users who delegate control of
their data to Cloud Service Providers (CSPs). The security model typically involves data owners, users,
CSPs, and Third-Party Auditors (TPAs).

Key Security Concerns for Data Owners and DBaaS Users:

1. Compromised Integrity and Confidentiality:

• Data Loss: May result from weak authentication, poor encryption practices, accidental
deletions, or operational failures.

• Integrity and Privacy: Threatened by missing or ineffective access control and poor
encryption key management.

• Confidentiality: Only authorized users should access data. Unencrypted data is highly
vulnerable to bugs and attacks.

• Insider Attacks: Superusers with full access rights can misuse sensitive data (e.g., medical or
business information).

• External Attacks: Spoofing, sniffing, man-in-the-middle, and side-channel attacks can lead to
data breaches and DoS attacks.

• Illegal Data Recovery: In multi-tenant environments, data can be recovered from improperly
sanitized storage devices.

• Data in Transit: Vulnerable during transfer across public networks; pre-transmission

encryption is essential.

2. Data Unavailability:

• Resource Exhaustion: Caused by vague user requirements or miscalculations.

• Consistency Failures: Due to hardware/software errors causing conflicting data views.

• Auditing Failures: Monitoring systems can fail, leading to undetected issues.

3. Transparency and Control:

• Data Provenance: Tracking data origins using metadata is resource-intensive but essential for
trust.

• Physical Location: Cloud users don’t know where their data is physically stored, complicating
breach response.

• Execution Control: Users lack fine-grained control or visibility into the execution
environment.

4. Replication and Backup:

• Consistency: Ensuring consistent replicas is complex.

• Timely Backups: Needed for fast recovery but can be a point of failure or attack.

5. Auditing and Monitoring:

 • Third-Party Auditing: While helpful, it introduces risks, especially when traditional auditing
methods require deep infrastructure access.

6. Data Privacy Laws:

• Jurisdictional Issues: Users may unknowingly violate laws (e.g., EU or South American data
residency regulations) due to unknown storage locations.[‘/

2. Explain Security Risks Posed by Shared Images & Management OS.

Security risks in cloud environments can arise from both the sharing of virtual machine images and
the management operating system responsible for orchestrating virtualized resources.

I. Security Risks Posed by Shared Images (e.g., Amazon Machine Images - AMIs)

Shared images, especially in IaaS models, present significant security risks if not properly managed by
both creators and users.

1. Image Creation and Bundling:

o AMIs can be created from running systems, other AMIs, or VM images. The process
(bundling) involves creating, compressing, encrypting, and uploading the image (e.g.,
to S3).

o Tools like ec2-bundle-image (loopback files) and ec2-bundle-volume (file system

level) are used.

2. Vulnerabilities Found in Audits of Shared AMIs:

o Residual Data: Many analyzed images allowed recovery of undeleted files,

credentials (passwords, SSH keys), private keys, and other sensitive information using
standard tools.

o Software Vulnerabilities: A high percentage of audited Windows and Linux AMIs

contained critical vulnerabilities, often due to outdated images.

o Backdoors and Leftover Credentials:

▪ SSH keys: Malicious AMI creators can leave their public SSH keys
in authorized_keys, allowing them remote login to any instance of that AMI.

▪ Password-based authentication: If enabled, and old passwords are not

removed, attackers can extract password hashes (e.g., using John the Ripper)
and crack them.

▪ Omission of cloud-init script: This script regenerates host SSH keys. Its
omission makes systems vulnerable to man-in-the-middle attacks if keys are
shared across instances. Tools like NMap can be used to match discovered
SSH keys.

o Unsolicited Connections: Modified syslog daemons in some Linux instances

forwarded sensitive event information (logins, web requests) to external agents.
Distinguishing legitimate (e.g., software updates) from malicious connections is
difficult.
 o Malware: Infected Windows AMIs were found with Trojans (e.g., Trojan-Spy for
keylogging and data theft, [Link] for decrypting Firefox passwords).

o Privacy Risks for Image Providers: Recovery of their own private keys (including AWS
API keys, leading to unauthorized cloud usage billed to the provider), IP addresses,
browser/shell history, and sensitive data from deleted files (if not properly wiped
using utilities like shred, scrub, zerofree, or wipe). Block-level image creation can
include blocks marked as free but containing old data.

II. Security Risks Posed by a Management OS (e.g., Dom0 in Xen)

While hypervisors are smaller than traditional OSs, the Trusted Computer Base (TCB) of a virtual
environment includes not only the hypervisor but also the Management OS (e.g., Xen's Dom0),
which handles VM creation, device drivers, live migration, and administrative tools.

• Diagram: Figure 11.4 (The trusted computing base of a Xen-based environment including
hardware, Xen, and Dom0 with its components like administrative tools, live migration,
device drivers, device emulation, and XenStore, supporting Guest OS/applications in DomU).

1. Vulnerabilities during VM (DomU) Creation by Management OS (Dom0):

o Denial-of-Service: Refusing to carry out steps to start a new VM.

o Kernel Modification: Modifying the guest OS kernel to allow third-

party monitoring/control .

o Integrity Undermining: Setting incorrect page tables or virtual CPU registers.

o Persistent Memory Access: Refusing to release foreign mapping, allowing continued

access to the VM's memory.

2. Vulnerabilities during Run-time Interaction:

o Split Drivers: Communication between DomU (frontend) and Dom0 (backend) via
shared memory rings can be a target.
 o Unencrypted Communication: Transport Layer Security (TLS) might not prevent a
malicious Dom0 from extracting cryptographic keys from DomU memory.

o XenStore: As a central repository for system state, it's a critical point. A malicious VM
could deny access or gain unauthorized access to a DomU's memory via XenStore.

3. Protecting DomUs from an Untrusted Management OS:

o Restricting Foreign Mapping: Prohibiting Dom0 from using foreign mapping unless
initiated by DomU via a hypercall, with data being encrypted.

o Hypercall Interception: Intercepting and controlling hypercalls between Dom0 and

DomU. Prohibiting debugging or IOMMU control hypercalls by Dom0.

o New Hypercalls for Security:

▪ vCPU Privacy/Integrity: Encrypting vCPU registers during save/restore

operations.

▪ VM Memory Privacy/Integrity: Encrypting memory pages handled by Dom0;

hypervisor calculating hashes for integrity.

▪ Freshness: Adding version numbers to hashes to ensure data freshness.

o This increased security incurs overhead in domain build, save, and restore times.

(Relevant OCR text: Module 4, Sections 11.10, 11.11)

3. Discuss how virtual machines are secured.

Virtual Machine (VM) security involves protecting VMs from various threats and leveraging
virtualization's inherent capabilities for enhanced security. The discussion often focuses on system
VMs where a hypervisor controls hardware access.

• Diagram: Figure 11.3A (Virtual security services provided by the hypervisor/Virtual Machine
Monitor) and Figure 11.3B (A dedicated security VM).
I. Inherent Security Advantages of Virtualization:

1. Isolation:

o VM technology provides stricter isolation between VMs than traditional OS process

isolation.

o Hypervisors control privileged operations, enforcing memory isolation and access to

disk and network.

o Hypervisors are less complex and better structured than traditional OSs, making
them potentially more resilient to attacks.

2. State Management for Security:

o The state of a guest VM (including its OS and applications) can be saved, restored,
cloned, and encrypted by the hypervisor.

o Cloning for Malicious Code Detection: A running system can be cloned, and
potentially dangerous applications can be tested on the clone to observe behavior
without affecting the production system.

o Replication: Ensures reliability and can support security objectives.

3. Inter-VM Communication: Moving guest VM files to a dedicated security VM can protect

them from attacks, leveraging faster inter-VM communication compared to physical machine
communication.

II. Threats and Challenges in VM Security:

1. Hypervisor-based Threats (NIST classification):

o Resource Starvation/DoS: Due to badly configured resource limits or a rogue VM

bypassing limits.

o VM Side-Channel Attacks: A rogue VM attacking other VMs on the same hypervisor

due to improper inter-VM traffic isolation, limitations of packet inspection, or
insecure VM images.

o Buffer Overflow Attacks in the hypervisor.

2. VM-based Threats (NIST classification):

o Deployment of Rogue/Insecure VMs: Unauthorized users creating insecure instances

or performing unauthorized administrative actions (creation, suspension, etc.) due to
improper access controls.

o Insecure/Tampered VM Images in Repository: Lack of access control to the image

repository or mechanisms to verify image integrity (e.g., digital signatures).

3. Challenges for Hypervisor Security Services: Hypervisors see raw data (e.g., disk blocks),
while security services often operate at a higher logical level (e.g., files).

4. Attacker Sophistication: Attackers can fingerprint VMs to avoid honeypots and may attempt
to access VM-logging files for sensitive data (e.g., cryptographic keys).

III. VM-based Security Mechanisms:

 1. Intrusion Detection Systems (IDS):

o VM-based IDS (e.g., Livewire, Siren) exploit VM capabilities for:

▪ Isolation: Containing threats within a VM.

▪ Inspection: The hypervisor can review the state of guest VMs.

▪ Interposition: The hypervisor can trap and emulate privileged instructions.

o Intrusion prevention systems (e.g., SVFS, NetTop, IntroVirt) also leverage these.

2. Trusted Computing Platforms:

o Systems like Terra use a trusted hypervisor to partition resources among VMs.

IV. Security of Virtualization (Broader Concepts):

• VM State Capture: The complete state of an OS within a VM can be saved to a file, copied,
and shared. This is useful for:

o IaaS delivery model (uploading application images).

o Increased reliability (replication to hot standby).

o Resource management (moving VMs for load balancing).

• Rollback Risk: A hypervisor's ability to record and roll back VM state can be exploited by
attackers to access sensitive data the owner attempted to destroy.

V. Cost of Virtualization Security:

• Higher hardware costs (more CPU, memory, disk, network bandwidth).

• Cost of developing hypervisors and modifying host OS (for paravirtualization).

• Overhead of virtualization due to hypervisor involvement in privileged operations.

(Relevant OCR text: Module 4, Sections 11.8, 11.9, parts of 11.2, 11.7)

4. Explain reputation system design options.

Reputation systems are designed to establish public opinion about the character or standing (e.g.,
honesty, reliability) of an entity, which could be a person, agent, product, or service. They aggregate
collective evaluations from a group. For cloud services, reputation systems can help protect data
centers and user communities.

• Diagram: Figure 4.36 (Design options of reputation systems for social networks and cloud
platforms, showing a two-tier classification: Centralized/Distributed at the first tier, and User-
oriented/Data center-based at the second tier, with examples like eBay, Google, Amazon,
PeerTrust, EigenTrust, PowerTrust).

Design Options for Reputation Systems:

1. Implementation Architecture (First Tier):

o Centralized Reputation Systems:

 ▪ Managed by a single central authority.

▪ Easier to implement.

▪ Demand more powerful and reliable server resources from the central
authority.

▪ Examples: Commercial systems by eBay, Google, and ‘Amazon for their

services.

o Distributed Reputation Systems:

▪ Involve multiple control centers working collectively.

▪ More complex to build.

▪ More scalable and reliable in handling failures.

▪ Often developed by academic research communities (e.g., Aberer and

Despotovic's P2P model, EigenTrust, PeerTrust, PowerTrust).

2. Scope of Reputation Evaluation (Second Tier):

o User-Oriented Reputation Systems:

▪ Focus on individual users or agents.

▪ Most P2P reputation systems belong to this category.

o Data Center-Oriented (or Resource Site-Oriented) Reputation Systems:

▪ Reputation is modeled for the resource site (e.g., data center) as a whole.

▪ Applies to products or services offered by the cloud.

▪ Commercial systems (eBay, Google, Amazon) often use this for their service
reputation.

Considerations for Reputation Systems in Clouds:

• Adaptation from P2P/Social Networks: Existing systems designed for P2P or social networks
can be converted for protecting cloud computing applications and data centers.

• Hierarchy: P2P reputation systems can be structured hierarchically to protect cloud resources
at the site level and data objects at the file level, demanding both coarse-grained and fine-
grained access control.

• Beneficiaries: Must benefit both cloud users and data centers.

• Integration with Other Security Mechanisms:

o Can assist in safe cloning of VMs (with snapshot control based on RPO).

o Support secured information logging and migration over secure virtual LANs.

o Work with sandboxes for safe execution platforms.

• Trust Overlay Networks:

 o Hwang and Li proposed building a trust overlay network to model trust relationships
among data-center modules, possibly structured with a Distributed Hash Table (DHT)
for fast aggregation of global reputations from local scores.

o Two-Layer Overlay (as per Figure 4.37):

▪ Bottom Layer: Distributed trust negotiation and reputation aggregation

(handles user/server authentication, access authorization, trust delegation,
data integrity).

▪ Top Layer: Fast virus/worm signature generation/dissemination, piracy

detection (facilitates worm containment, IDSes).

o Content poisoning (reputation-based) can stop copyright violations.

o Enables trusted interactions between users and data-center owners.

o Privacy can be enforced by matching colored user IDs with colored data objects.

Reputation systems aim to create a trusted cloud environment by providing objective evaluations,
which, when combined with SLAs and security policies, enhance the overall security and reliability of
cloud services.

(Relevant OCR text: Module 3, Section 4.6.4)

5. What are the various system issues for running a typical parallel program in either parallel or
distributed manner?

Running a parallel program on a distributed computing system involves several system issues that
need to be managed to ensure correct and efficient execution. These issues abstract the complexities
of parallel execution from the user to varying degrees depending on the programming paradigm.

The key system issues include:

1. Partitioning: This is applicable to both computation and data.

o Computation Partitioning:

▪ Involves splitting a given job or program into smaller, concurrently

executable tasks.

▪ Success depends on correctly identifying portions of the program that can

run in parallel.

▪ These parallel parts might process different data or different copies of the
same data.

o Data Partitioning:

▪ Involves splitting the input or intermediate data into smaller pieces.

▪ If parallelism exists in the input data, it can be divided for processing on

different workers.
 ▪ These data pieces might be processed by different parts of a program or by
copies of the same program.

2. Mapping:

o Assigns the smaller parts of the program (tasks) or the smaller pieces of data to the
underlying resources (e.g., workers, computation engines).

o This process aims to appropriately assign these units for simultaneous execution on
different workers.

o Typically handled by resource allocators within the system.

3. Synchronization:

o Necessary because different workers may perform different tasks or operate on

shared data.

o Prevents race conditions (where multiple workers access a shared resource

concurrently in an uncontrolled manner).

o Manages data dependency (where one worker needs the processed data from
another worker before it can proceed).

o Ensures coordination among workers.

4. Communication:

o Triggered primarily by data dependency among workers.

o Involves the transfer of intermediate data between workers.

o The efficiency of communication is critical for the overall performance of the parallel
program.

5. Scheduling:

o Task/Data Piece Scheduling: When the number of computation parts (tasks) or data
pieces exceeds the number of available workers, a scheduler selects a sequence of
tasks/data pieces to be assigned to workers. The scheduler decides the order based
on a scheduling policy, while the resource allocator does the actual mapping.

o Job/Program Scheduling: For multiple jobs or programs, if system resources are

insufficient to run them all simultaneously, a scheduler selects a sequence of
jobs/programs to be run on the distributed computing system.

Addressing these issues manually can be very time-consuming and requires specialized programming
knowledge, potentially detracting from the core application logic and affecting programmer
productivity and time-to-market. Parallel and distributed programming paradigms and models (like
MapReduce) aim to abstract many of these details from users.

(Relevant OCR text: Module 5, Section 6.2.1)

6. With a neat diagram, explain the data flow in running a MapReduce job at various task trackers
using Hadoop Library.
Running a MapReduce job in Hadoop involves interactions between a user node, a single JobTracker
(master), and several TaskTrackers (slaves). The JobTracker manages the overall job, while
TaskTrackers execute individual map or reduce tasks.

• Diagram: Figure 6.12 (Data flow in running a MapReduce job at various task trackers using
the Hadoop library. This diagram should show the User submitting a job (via runJob(conf)),
the JobTracker, and multiple TaskTrackers. Arrows should indicate: job submission to
JobTracker, task assignment from JobTracker to TaskTrackers, TaskTrackers running Map tasks
(on JVMs, reading from DataNodes/Blocks) and Reduce tasks (on JVMs, potentially HMM -
Hadoop MapReduce Master interaction for shuffle/sort), and heartbeats from TaskTrackers
to JobTracker). Data Flow and Process:

The data
flow starts when a user calls the runJob(conf) function within their program on a user node.
The conf object contains tuning parameters for MapReduce and HDFS.

1. Job Submission:

o Request Job ID: The user node contacts the JobTracker to request a new job ID.

o Compute Input Splits: The user node computes the input file splits. Typically, HDFS
blocks are used as input splits.

o Copy Resources: The user node copies necessary resources for the job (e.g., the job's
JAR file, configuration files, computed input splits) to the JobTracker's file system
(which is usually HDFS).

o Submit Job: The user node calls the submitJob() function, formally submitting the job
to the JobTracker.

2. Task Assignment (by JobTracker):

o Map Task Creation: The JobTracker creates one map task for each input split
computed by the user.

o Map Task Assignment: The JobTracker assigns these map tasks to available execution
slots on the TaskTrackers.

▪ Data Localization: The JobTracker considers data locality when assigning map
tasks. It tries to assign a map task to a TaskTracker running on the same
DataNode that stores the input split for that task. If not possible, it tries a
TaskTracker on the same rack, and then any available TaskTracker.
 o Reduce Task Creation: The JobTracker also creates a predetermined number of
reduce tasks (specified by the user).

o Reduce Task Assignment: These reduce tasks are assigned to available TaskTrackers.
There's typically no data locality consideration for reduce tasks in the initial
assignment phase, as they process intermediate data from multiple map tasks.

3. Task Execution (by TaskTracker):

o Copy JAR File: The TaskTracker first copies the job JAR file from HDFS to its local file
system.

o Launch JVM: It then launches a new Java Virtual Machine (JVM) to execute the map
or reduce task.

o Map Task Execution: The map task processes its assigned input split, performing the
user-defined map function and generating intermediate key-value pairs.

o Reduce Task Execution: The reduce task fetches relevant intermediate data from map
tasks (shuffling), sorts it, and then processes it using the user-defined reduce
function to produce the final output.

4. Task Running Check (Heartbeats):

o TaskTrackers send periodic heartbeat messages to the JobTracker.

o These heartbeats notify the JobTracker that the TaskTracker is alive and indicate
whether it's ready to run new tasks or if its current tasks are progressing.

o The JobTracker uses these heartbeats to monitor job progress and handle failures
(e.g., by re-scheduling failed tasks).

Each TaskTracker node has a number of simultaneous execution slots (determined by CPU cores and
thread capacity), and each slot can execute either a map or a reduce task. There's a one-to-one
correspondence between map tasks and data blocks processed in their respective DataNodes,
facilitated by the TaskTracker.

(Relevant OCR text: Module 5, Section [Link])

7. Discuss Programming the Google App Engine.

Google App Engine (GAE) provides a Platform-as-a-Service (PaaS) for developing and hosting web
applications in Google's scalable infrastructure. It abstracts much of the underlying system
administration and focuses on application development.

• Diagram: Figure 6.17 (Programming environment for Google AppEngine, showing Datastore,
Memcache, Blobstore, Python/Java application, URL fetch, Users, Mail, Cron, Images, Google
app secure data connection SDC, Secure intranet, Admin console, Google corporate apps,
and Google data API). Additional Diagrams (Conceptual for GFS/BigTable/Chubby): Figures
6.18 (GFS Architecture), 6.19 (GFS Data mutation), 6.20 (BigTable data model and system
structure), 6.21 (BigTable Tablet location hierarchy).
 Key Components and Programming Features of GAE:

1. Application Runtime Environment:

o Supports development in Python and Java.

o Python environment can use frameworks like Django, CherryPy, or Google's built-
in webapp.

o Java environment allows JVM-based languages (e.g., JavaScript via Rhino, Ruby via
JRuby) and uses a client environment with an Eclipse plug-in and Google Web Toolkit
(GWT).

2. Datastore:

o A NoSQL data management system based on BigTable.

o Stores entities (objects up to 1MB) with schema-less properties.

o Queries can retrieve entities of a given kind, filtered and sorted by property values.

o Java Interfaces: Java Data Object (JDO) and Java Persistence API (JPA) via Data
Nucleus.

o Python Interface: A SQL-like query language called GQL.

o Consistency: Strongly consistent. Uses optimistic concurrency control.

o Transactions: Supports transactions on "entity groups" (entities stored together for

efficient, atomic operations).
 3. Storage Services:

o Memcache: In-memory caching to enhance Datastore performance. Can be used

independently.

o Blobstore: For large files (size limit 2GB), suitable for serving static content like
images or videos.

o Google File System (GFS): The underlying fundamental storage service, designed for
large files, high fault tolerance (replication, checksums), and append-heavy
workloads. GFS has a single master for metadata and multiple chunkservers. (Figure
6.18, 6.19)

o BigTable: A distributed, multi-level sparse map built on GFS, used by the Datastore. It
handles structured and semi-structured data, indexed by row key, column key, and
timestamp. Tables are split into "tablets." (Figure 6.20, 6.21)

4. Services and APIs:

o URL Fetch: Allows applications to fetch resources and communicate with other hosts
over HTTP/HTTPS.

o Mail Service: Specialized mechanism to send emails from GAE applications.

o Users Service (Google Accounts): Handles user authentication and sign-in, allowing
users with existing Google accounts to use GAE apps.

o Images Service: Manipulates image data (resize, rotate, flip, crop, enhance).

o Cron Service: Schedules tasks to run at regular intervals (e.g., daily, hourly).

o Task Queues: Allows applications to perform background tasks outside of user

requests, useful for deferring work.

o Google Data API: Access to Google's corporate facilities like Maps, Sites, Calendar,
Docs, YouTube.

5. Development and Deployment:

o Software Development Kit (SDK): Provided for local application development and
testing. Includes tools to simulate GAE services locally.

o Administration Console: For managing application deployment cycles, monitoring,

and configuring services (not for physical resource management).

o Quotas: GAE applications consume resources up to certain limits (quotas). Use is free
up to these quotas; exceeding them incurs charges.

6. Underlying Infrastructure (Invisible to most programmers but key to GAE's capabilities):

o Chubby: A distributed lock service used for master election in GFS and BigTable, and
for location bootstrapping. (Figure 6.22 implies its structure).

GAE is designed for web applications that require high scalability and reliability, offloading
infrastructure management to Google. It emphasizes a specific application model and provides a rich
set of services tailored for web development.
(Relevant OCR text: Module 5, Sections 6.3, 4.4.2; Figures 6.17-6.22)

8. With neat diagram, explain OpenStack Nova system architecture.

OpenStack Compute, codenamed Nova, is an Infrastructure-as-a-Service (IaaS) cloud computing

fabric controller. It's designed with a shared-nothing architecture and relies heavily on messaging-
based information exchange to manage large groups of virtual private servers.

• Diagram: Figure 6.30 (OpenStack Nova system architecture. This diagram should show the
User Manager (LDAP), API server (Boto), Cloud controller (AMQP), S3 (Tornado), Nodes
(Libvirt/KVM), and Storage (ATA over Ethernet). Key communication protocols like HTTP,
AMQP, LDAP should be indicated between components).

Core
Architectural Concepts and Components of OpenStack Nova:

1. Shared-Nothing Architecture:

o Most components are designed to be independent and do not share state directly.

o The overall system state is kept in a distributed data system (not explicitly shown as a
single box in Fig 6.30, but implied by the interaction of components).

o State updates are made consistent through atomic transactions.

2. Messaging-Based Communication:

o Most communication between Nova components is facilitated by message queues

(e.g., AMQP - Advanced Messaging Queuing Protocol, as indicated connecting the
Cloud Controller to Nodes and S3 in Figure 6.30).

o This prevents blocking components while waiting for responses; deferred objects
and callbacks are used.

3. Key Components:

o API Server:

▪ Receives HTTP requests from clients (e.g., using boto, an Amazon API library
in Python).

▪ Converts commands to and from the API format.

 ▪ Forwards requests to the Cloud Controller.

o Cloud Controller:

▪ The central management point of Nova.

▪ Maintains the global state of the system.

▪ Ensures authorization by interacting with the User Manager.

▪ Manages compute nodes, storage workers (via the S3 service), and

networking components through a message queue.

o User Manager:

▪ Handles user authentication and authorization.

▪ Typically interacts with the Cloud Controller via LDAP (Lightweight Directory
Access Protocol).

o Compute Nodes (Nodes):

▪ Physical servers where VMs run.

▪ Managed by hypervisors like KVM or Xen (interfaced via Libvirt, as shown in

Fig 6.30).

▪ Receive instructions from the Cloud Controller via the message queue.

o Storage:

▪ Object Storage (S3-like service): Implemented, for instance, using Tornado (a

fast HTTP server) to provide S3 capabilities within OpenStack. Interacts with
the Cloud Controller via AMQP.

▪ Block Storage (Nodes managing ATA over Ethernet): Provides persistent

block storage for VMs.

o Networking Components (Conceptual, managed by Nova):

▪ NetworkController: Manages IP addresses and VLAN allocations.

▪ RoutingNode: Handles NAT conversion of public IPs to private IPs and

enforces firewall rules.

▪ AddressingNode: Runs DHCP services for private networks.

▪ TunnelingNode: Provides VPN connectivity.

Network state (VLAN assignments, IP allocations) is managed in the
distributed object store.

Implementation Details:

• Nova is primarily implemented in Python.

• It utilizes externally supported libraries and components like boto and Tornado.
The architecture aims for scalability and resilience by distributing responsibilities and using
asynchronous communication. It allows for managing virtual machines, storage, and networking in a
cohesive IaaS environment.

(Relevant OCR text: Module 5, Section [Link])

9. Explain the security risks faced by cloud users and cloud service providers.

Both cloud users and Cloud Service Providers (CSPs) face a multitude of security risks, stemming from
the shared, multi-tenant nature of cloud computing and the reliance on internet-based access.

I. Security Risks Faced by Cloud Users (User Concerns - Section 11.1):

1. Unauthorized Access to Confidential Information and Data Theft:

o Data Vulnerability: Data is often more vulnerable in storage (long-term exposure)

than during processing (short-term exposure). Storage server security and data in
transit security are critical.

o Rogue Employees of CSP: Insider attacks from CSP employees are a concern as
hiring/screening policies are opaque to users.

2. Lack of Control over Data Lifecycle:

o Data Deletion: Virtually impossible for a user to verify if data marked for deletion
was actually deleted and if the media was wiped, preventing recovery by subsequent
users.

o Seamless Backups: CSPs perform backups without user knowledge/consent, which

can lead to data records being lost, accidentally deleted, or becoming accessible to
attackers during this process.

3. Lack of Standardization and Interoperability:

o Questions regarding service interruption, access to data during blackouts, price

hikes, and the cost/feasibility of moving to a different CSP remain.

4. Auditing and Compliance:

o Achieving a full audit trail on a cloud is often unfeasible, posing significant

challenges.

5. Evolving Technology (e.g., Autonomic Computing):

o Future technologies like self-organizing, self-optimizing, self-repairing systems could

introduce new, harder-to-trace security threats.

6. Multi-tenancy:

o The root cause of many user concerns. Threats differ by cloud model (e.g., SaaS
private info compromise affects many users).

7. Legal Framework and Data Sovereignty:

o Rapid technology evolution outpaces legislation.

 o Uncertainty about applicable laws (user's country, CSP's country, data center
location, data transit countries).

o CSP outsourcing data handling to other companies in different countries complicates

legal accountability.

o Law enforcement data requests (e.g., subpoenas for emails) can compromise privacy.

8. Traditional Threats Amplified (Section 11.2):

o The vast amount of cloud resources and large user populations amplify the impact of
traditional threats (DDoS, phishing, SQL injection, cross-site scripting).

o User-site infrastructure (used to connect to the cloud) may be outside their firewall.

o Difficulty in identifying attacker paths in multi-VM environments.

9. Availability of Services:

o System failures, power outages can shut down services.

o Data lock-in can prevent business function during outages.

o Uncertainty about the correctness of application results.

10. Third-Party Control and Lack of Transparency:

o CSP subcontracting to less trustworthy third parties.

o Poor quality hardware suppliers leading to data loss.

o CSP espionage.

o Contractual obligations often place all data security responsibility on the user (e.g.,
Amazon's agreement).

II. Security Risks Faced by Cloud Service Providers:

While many user risks indirectly impact CSPs (reputation, liability), some are more direct:

1. Abusive Use of Cloud Resources (CSA Threat):

o Users leveraging cloud instances (e.g., IaaS) to launch DDoS attacks, distribute
spam/malware. This requires CSPs to implement mechanisms to prevent nefarious
use.

2. Insecure APIs (CSA Threat):

o If APIs for authentication, access control, monitoring are not secure, they can be
exploited to compromise the platform or user data.

3. Shared Technology Vulnerabilities (CSA Threat):

o Flaws in hypervisors supporting multi-tenancy can allow guest OS to affect platform

security or other VMs.

4. Malicious Insiders (CSA Threat):

 o CSP employees with privileged access can cause significant harm. CSPs need robust
internal controls and monitoring.

5. Traditional Attacks Targeting CSP Infrastructure:

o DDoS attacks against CSP services, phishing targeting CSP admin credentials, SQL
injection against CSP management portals.

6. Maintaining Availability and Resilience:

o Protecting against system failures, power outages, and natural disasters to meet
SLAs.

7. Compliance and Legal Obligations:

o Adhering to various regional and international data protection laws (e.g., GDPR,
HIPAA), especially concerning data location and cross-border data transfer.

o Responding to law enforcement requests while respecting user privacy.

8. Defense against Advanced Persistent Threats (APTs):

o Sophisticated, targeted attacks aiming to steal data or disrupt CSP operations.

9. Scalability of Security Measures:

o Ensuring security mechanisms can scale with the growth of users and resources.

10. Reputation Damage from Breaches:

o Any security incident, whether affecting users or the CSP directly, can severely
damage the CSP's reputation and business.

Security Defense Strategies for CSPs (from Module 3, Section 4.6.1):

• Facility Security: On-site security, biometric readers, CCTV, motion detection.

• Network Security: Fault-tolerant firewalls, IDS/IPS, third-party vulnerability assessments.

• Platform Security: SSL, data encryption, strict password policies, system trust certification.

• Protecting Servers/Hypervisors/VMs: From malware, software attacks, vulnerabilities, and

DoS.

• Data Protection: From theft, corruption, and natural disasters.

• Authenticated/Authorized Access.

(Relevant OCR text: Module 4, Sections 11.1, 11.2; Module 3, Section 4.6)

10. Discuss about privacy and the import of privacy.

Privacy is a fundamental concept referring to the right of an individual, group, or organization to

keep personal or proprietary information from being disclosed. It's widely recognized, with many
nations viewing it as a basic human right.

I. Definition and Importance:

 • Universal Declaration of Human Rights (Article 12): States, "No one shall be subjected to
arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon
his honor and reputation. Everyone has the right to the protection of the law against such
interference or attacks."

• Legal Protections:

o U.S. Constitution: While no express right to privacy, the Bill of Rights reflects
concerns for protecting specific aspects (e.g., 1st Amendment - beliefs, 3rd - home,
4th - person/possessions against unreasonable searches, 5th - self-
incrimination/personal information).

o United Kingdom: Guaranteed by the Data Protection Act.

o European Court of Human Rights: Developed many documents defining the right to
privacy.

• Limitations: The right to privacy is not absolute and is limited by laws (e.g., taxation laws
requiring income disclosure). It can also conflict with other basic human rights like freedom
of speech. Privacy laws differ significantly from country to country.

II. Privacy in the Digital Age and Cloud Computing:

The digital age has introduced new and significant challenges to privacy:

1. New Threats:

o Personal information voluntarily shared but subsequently stolen or misused can lead
to identity theft.

o The "right to be forgotten" (a new EU privacy right) addresses the persistence of

digital information (photos, status updates, tweets) online.

2. Cloud-Specific Privacy Concerns (especially for public clouds):

o Data Residency: Data, often unencrypted, resides on servers owned by a CSP, giving
users less control.

o Services Based on Personal Information: Services leveraging individual preferences,

location, social network memberships, etc., pose special risks. Users cannot solely
rely on CSPs to guarantee data privacy.

o Varying Concerns by Delivery Model: Privacy implications differ for IaaS, PaaS, and
SaaS.

o Example - Gmail Privacy Policy: Collects user-provided information (name, email,

credit card) and usage information (device, log, location, cookies). Shares
information if legally required or to protect Google/users/public, or aggregated non-
personally identifiable information.

3. Main Aspects of Cloud Privacy (as per [400]):

o Lack of User Control: User-centric data control is often incompatible with cloud
usage. Once data is on CSP servers, users lose control over its exact location and
 sometimes even access (e.g., Gmail user has no control over where emails/backups
are stored).

o Potential Unauthorized Secondary Use: CSPs might use data for purposes like
targeted advertising without explicit consent. Technological prevention is difficult.

o Data Proliferation: Data is copied, backed up, and moved, increasing the risk of
exposure.

o Dynamic Provisioning (Outsourcing Threats): Fuzzy issues regarding CSP

subcontractors: their identity, their rights to the data, and data transferability in
cases of bankruptcy or merger.

III. Addressing Privacy Challenges:

1. Legislation:

o Some countries (e.g., EU with strict laws like GDPR) are more aggressive in
addressing new privacy concerns.

o The Federal Trade Commission (FTC) for the US Congress proposed that consumer-
oriented commercial websites comply with four widely-accepted fair information
practices:

▪ Notice: Clear notice of information practices (what's collected, how, why,

disclosure, security).

▪ Choice: Offer consumers choices about how personal identifying information

is used beyond the initial purpose (internal/external secondary uses).

▪ Access: Reasonable access for consumers to review, correct, or delete their

collected information.

▪ Security: Take reasonable steps to protect collected information. Legislation

should be general and technologically neutral.

2. Privacy Impact Assessment (PIA):

o Tools and processes to identify privacy issues in information systems.

o No international standards as of mid-2017, but various countries/organizations

require PIA reports (e.g., assessing UK-US Safe Harbor for EU Directive 95/46/EC
compliance).

o Promotes a proactive attitude, embedding privacy rules in new systems ab initio.

o A PIA tool (e.g., web-based service) could take project info, documents, risks,
stakeholders as input and produce a PIA report (findings, risk summary, security,
transparency, cross-border data flows).

o Often uses a knowledge base (KB) created by domain experts and questionnaires
filled by users. An expert system infers rules and executes based on priority.

(Relevant OCR text: Module 4, Section 11.3)

11. Write a note on operating system security.

Operating System (OS) security is fundamental to protecting applications and data by managing how
multiple applications share hardware resources subject to defined policies. A critical OS function is to
defend against malicious attacks like unauthorized access, code tampering, and spoofing, even on
single-user systems.

Key Concepts in OS Security:

1. Mandatory Security ([295]):

o Defined as "any security policy where the definition of the policy logic and the
assignment of security attributes is tightly controlled by a system security policy
administrator."

o Elements include:

▪ Access Control Policies: Specify how the OS controls access to system

objects.

▪ Authentication Usage Policies: Define mechanisms for authenticating

principals.

▪ Cryptographic Usage Policies: Specify mechanisms for data protection.

o A necessary condition is that security-related subsystems are tamper-proof and

cannot be bypassed.

o An OS should confine an application to a unique security domain.

2. Trusted Applications and Privileges:

o Applications performing security-related functions with special privileges are trusted

applications.

o They should operate with the lowest level of privileges necessary (e.g., via type
enforcement).

o Discretionary security mechanisms place the burden on individual users and can be
changed by applications without user consent, unlike mandatory policies which
require administrator changes.

3. Limitations of Commercial OSs:

o Often do not support multi-layered security, distinguishing only between fully

privileged and unprivileged domains.

o Some (e.g., Windows NT) allow programs to inherit all privileges of the invoking
program, regardless of trust.

4. Trusted Paths:

o Mechanisms supporting user interactions with trusted software are critical. Without
them, malicious software can impersonate trusted software.

o Some systems provide trusted paths for limited functions (login, password change).
 o Solution: Decompose complex mechanisms into components with well-defined roles
(e.g., access control into enforcer and decider).

▪ The enforcer gathers information about the agent and object, passes it to
the decider for a policy decision, and then carries out the action.

▪ A trusted path is needed to prevent malicious software from tampering with

object attributes/policy rules or impersonating the decider. Similar
decomposition applies to cryptography usage.

5. Protecting Against Malicious Mobile Code:

o Java Security Manager uses type-safety for sandboxing, but JVMs can accept
bytecode violating language semantics and cannot protect themselves from
tampering by other applications.

o Security relies on file system integrity for Java class code. Digitally signed applets
from trusted sources can fail due to the all-or-nothing security model.

o Confining a browser to a distinct security domain is a potential solution.

6. Closed-Box vs. Open-Box Platforms:

o Specialized closed-box platforms (cell phones, ATMs) may have embedded

cryptographic keys for identity/software authentication.

o Open-box platforms (commodity OS hardware) lack these facilities.

Overall Assessment of Commodity OS Security:

• Offer low assurance due to complexity (millions of lines of code) and vulnerability to many
attacks.

• Poorly isolate applications; a compromised application can affect the entire platform.

• Provide weak mechanisms for inter-application authentication and lack trusted paths
between users and applications. These shortcomings are problematic in distributed
computing.

Application-specific security implemented above the OS can sometimes be more effective (e.g.,
digital signatures in e-commerce).

(Relevant OCR text: Module 4, Section 11.7)

12. Write a note on virtual machine security.

Virtual Machine (VM) security is a critical aspect of cloud computing, focusing on protecting the
integrity, confidentiality, and availability of VMs and the data they process. It leverages
virtualization's inherent capabilities while also addressing new threats introduced by the virtualized
environment.

• Diagrams: Figure 11.3A (Virtual security services by hypervisor) and 11.3B (Dedicated
security VM) would be relevant here.

Key Aspects of VM Security:

1. Isolation:

o Hypervisors provide stronger isolation between VMs than traditional OS process

isolation by controlling privileged operations, memory, disk, and network access.

o This helps contain threats within a compromised VM, preventing them from
spreading to others on the same physical host.

2. Hypervisor's Role:

o As the control point, the hypervisor's security is paramount. It's generally less
complex than a full OS, potentially reducing its attack surface.

o Hypervisors can inspect VM states, interpose on privileged operations, and provide

security services directly or through a dedicated security VM.

3. VM State Management for Security:

o The ability to save, restore, clone, and encrypt VM states is crucial.

o Cloning allows for testing potentially malicious applications in an isolated copy.

o Replication enhances reliability and can support security objectives.

4. Threats to VMs:

o Hypervisor-based: Resource starvation, side-channel attacks between VMs, buffer

overflows in the hypervisor.

o VM-based: Deployment of rogue/insecure VMs, use of tampered VM images from

repositories.

o VM Escape: An attack where malicious code in a guest VM breaks out of the VM to

gain access to the hypervisor or other VMs.

5. Security Mechanisms:

o VM-based Intrusion Detection/Prevention Systems (IDS/IPS): Leverage hypervisor

capabilities (inspection, interposition, isolation) to monitor and protect VMs.

o Trusted Hypervisors: Platforms like Terra use a trusted hypervisor to partition

resources and enforce security policies.

o Secure VM Images: Ensuring images are from trusted sources, regularly patched,
and their integrity verified (e.g., via digital signatures).
 o Careful Management of VM Logging Files: To prevent unauthorized access to
sensitive data like cryptographic keys.

6. Security of Virtualization Itself:

o While VM state capture is useful (for IaaS, reliability, load balancing), the rollback
capability can be a risk if an attacker accesses previous states containing sensitive
data that was meant to be destroyed.

Securing VMs requires a multi-layered approach, addressing vulnerabilities in the hypervisor, the
guest OS, applications within the VM, and the management plane that controls VM lifecycle and
image repositories.

(Relevant OCR text: Module 4, Sections 11.8, 11.9, 11.2)

13. Discuss about the system issues for running a parallel program in either a parallel or distributed
manner.

(This question is identical to question 5. The answer is a reiteration of the key points.)

Running a parallel program effectively, whether on a tightly coupled parallel system or a distributed
system, involves addressing several fundamental system issues. These issues are often abstracted by
parallel programming paradigms to simplify development.

The core system issues include:

1. Partitioning: Breaking down the problem.

o Computation Partitioning: Dividing the overall job/program into smaller,

concurrently executable tasks. This requires identifying the inherent parallelism in
the program's structure.

o Data Partitioning: Splitting the input data or intermediate data into smaller chunks
for parallel processing by different workers or tasks.

2. Mapping:

o Assigning the partitioned computational tasks or data pieces to the available

underlying resources (e.g., processors, workers, nodes). This is typically handled by a
resource allocator.

3. Synchronization:

o Coordinating the execution of different workers or tasks, especially when they share
data or have dependencies.

o Essential to prevent race conditions (uncontrolled concurrent access to shared

resources) and to manage data dependencies (where one task's input depends on
another's output).

4. Communication:

o The exchange of data and control information between different workers or tasks.
 o Often necessitated by data dependencies identified during partitioning. Efficient
communication is crucial for performance.

5. Scheduling:

o Determining the order and timing of execution for tasks or jobs, especially when the
number of tasks exceeds available resources or when multiple jobs compete for
resources.

o A scheduler applies a policy to select the next task/job, while the mapper (resource
allocator) assigns it to a worker.

Effectively managing these issues is critical for achieving the desired speedup and efficiency from
parallel execution. Modern parallel programming models aim to automate or simplify the handling of
these complexities for the programmer.

(Relevant OCR text: Module 5, Section 6.2.1)

14. Explain the architecture of Google File System.

The Google File System (GFS) is a large-scale, distributed file system designed and built by Google
primarily as the fundamental storage service for its search engine and other data-intensive
applications. It is optimized for Google's specific workload patterns, which involve huge files, append-
heavy writes, and large streaming reads.

• Diagrams: Figure 6.18 (Architecture of Google File System, showing Application/GFS client,
GFS master with file namespace and chunk locations, and multiple GFS chunkservers with
Linux file systems storing chunk data. Control and data messages should be distinguished)
and Figure 6.19 (Data mutation sequence in GFS, illustrating the client-master-primary
replica-secondary replicas interaction for writes).

•
1. xeeeeeeeeeCore Components:

o Single Master:
 ▪ Manages all file system metadata, including the namespace (directory tree),
access control information, mapping from files to chunks, and current
locations of chunk replicas.

▪ Controls system-wide activities like chunk lease management, garbage

collection of orphaned chunks, and chunk migration between chunkservers.

▪ Periodically communicates with chunkservers via HeartBeat messages to

give instructions and collect state.

▪ To mitigate the single point of failure and bottleneck issues, the master's
operations are minimized for data transfer (clients read/write data directly
to/from chunkservers), and its state is replicated to shadow masters for fault
tolerance.

o Multiple Chunkservers:

▪ Store file data on their local disks as chunks. Chunks are fixed-size (typically
64 MB).

▪ Each chunk is identified by a globally unique 64-bit chunk handle assigned by

the master at creation time.

▪ Chunkservers read or write chunk data specified by a chunk handle and byte
range.

▪ They do not cache file data; Linux buffer cache is relied upon.

o GFS Clients:

▪ Application code linked with the GFS client library.

▪ Communicate with the master for metadata operations but directly with
chunkservers for all data-bearing operations.

▪ Do not cache metadata but may cache data.

2. Chunk Management and Replication:

o Files are divided into fixed-size chunks (64 MB).

o Each chunk is replicated on multiple chunkservers (typically 3 replicas) for fault

tolerance and availability. Replicas are placed on different racks to guard against
rack-level failures.

o The master manages replica placement and re-replication upon chunkserver failures.

3. Data Operations:

o Read: The client asks the master for chunk locations. The master replies with
locations of replicas. The client caches this and contacts the nearest chunkserver to
read the data.

o Write/Append (Mutations):

▪ The client asks the master for the chunkserver holding the lease for the
chunk (the primary replica) and locations of other (secondary) replicas.
 ▪ The client pushes data to all replicas (data flow).

▪ Once all replicas acknowledge data receipt, the client sends a write request
to the primary (control flow).

▪ The primary assigns a serial order to mutations and applies them to its local
state.

▪ The primary forwards the write request (and serial order) to all secondary
replicas, which apply the mutation in the same order.

▪ Secondaries reply to the primary; the primary replies to the client. (Figure
6.19 illustrates this).

o Record Appends: GFS supports atomic appends where a client specifies only the
data; GFS appends it at least once atomically at an offset of its choosing and returns
the offset to the client. This is crucial for concurrent producer-consumer queue
applications.

4. Fault Tolerance:

o Fast Recovery: Master and chunkservers are designed to restart quickly.

o Chunk Replication: Handles chunkserver failures.

o Shadow Master: Replicates master state for master failure recovery.

o Checksumming: Each 64 KB block within a chunk has checksums for data integrity
verification.

5. Interface:

o GFS provides a familiar file system interface but it's not strictly POSIX-compliant. It
includes custom operations like snapshot and record append.

GFS's architecture successfully addresses the needs of Google's large-scale applications by

prioritizing fault tolerance, high aggregate throughput, and scalability, sometimes at the cost of
POSIX compliance or low latency for individual small operations.

(Relevant OCR text: Module 5, Section 6.3.2)

15. Write a note on Amazon Simple Storage Service.

Amazon Simple Storage Service (S3) is a highly scalable, reliable, and low-latency data storage service
offered by Amazon Web Services (AWS). It provides an object storage model, allowing users to store
and retrieve any amount of data, at any time, from anywhere on the web.

• Diagram: Figure 6.24 (Amazon S3 execution environment, showing User, REST interface,
SOAP interface, a Bucket with multiple Objects, each Object having Key, Value, Metadata,
 Access control, all on top of a Virtualization layer and underlying physical storage).

Key Features and Concepts of Amazon S3:

1. Object Storage Model:

o The fundamental unit of storage is an object.

o Objects are stored in buckets. A bucket is a container for objects and has a globally
unique name.

o Each object within a bucket is uniquely identified by a key (a developer-assigned

name).

o From a programmer's view, S3 provides a coarse-grained key-value store.

2. Object Attributes:

o Value: The actual data content of the object (from 1 byte to 5 terabytes).

o Metadata: A set of name-value pairs that describe the object (e.g., content-type,
last-modified). Custom metadata can also be associated.

o Access Control Information: ACLs define who can access the object and what
permissions they have (read, write, etc.).

3. Access Interfaces:

o REST (Representational State Transfer): A simple HTTP-based interface.

o SOAP (Simple Object Access Protocol): A standard web services interface.

o Users can interact with S3 via these interfaces using browsers, AWS SDKs, or third-
party tools.

4. Key Features:

o Scalability: Designed to handle virtually unlimited amounts of data and high request
rates.
 o Durability: Engineered for 99.999999999% (11 nines) durability of objects over a
given year. This is achieved through redundant storage across multiple facilities and
devices.

o Availability: Designed for 99.99% availability of objects over a given year.

o Reduced Redundancy Storage (RRS): A lower-cost storage option offering reduced

durability (99.99%) for non-critical, reproducible data.

o Security:

▪ Authentication mechanisms to ensure data is secure from unauthorized

access.

▪ Objects can be private (default) or public.

▪ Fine-grained access control via ACLs per object or per bucket.

▪ Server-Side Encryption (SSE) and client-side encryption options.

o Versioning: Allows keeping multiple versions of an object in the same bucket,

protecting against accidental deletions or overwrites.

o Lifecycle Management: Define rules to automatically archive objects to Amazon

Glacier (long-term, low-cost archival storage) or delete them after a certain period.

o Static Website Hosting: Buckets can be configured to host static websites.

o Logging: Provides access logs for buckets for auditing and tracking requests.

5. Data Transfer and Pricing:

o Data transfer into S3 is generally free.

o Data transfer out of S3 is charged, with pricing varying by region and volume.

o Storage is charged per GB per month, with tiered pricing (cost per GB decreases with
higher total storage).

o Requests (PUT, COPY, POST, LIST, GET) are also charged.

o No charge for data transfer between Amazon EC2 and Amazon S3 within the same
region.

6. Use Cases:

o Backup and archival.

o Content storage and distribution (e.g., for websites, mobile apps).

o Big data analytics (as a data lake for services like Amazon EMR, Redshift, Athena).

o Disaster recovery.

S3 serves as a foundational storage layer for many AWS services and customer applications due to its
robustness, scalability, and rich feature set.

(Relevant OCR text: Module 5, Section 6.4.2)

16. Write a note on emerging cloud software environments.

Several emerging cloud software environments, primarily open-source, aim to provide IaaS
capabilities, allowing organizations to build and manage their own private or hybrid clouds. These
environments offer alternatives to proprietary public cloud solutions and foster innovation in cloud
infrastructure management.

1. Eucalyptus:

o Origin: Research project at UC Santa Barbara, now Eucalyptus Systems.

o Goal: Bring cloud computing to academic supercomputers/clusters; provide AWS-

compliant IaaS.

o Architecture: (Figure 6.26 would illustrate the management platform, CLC,

Virtualized Network, CC, SC, NC, Walrus for storage, and interaction with external
clouds).

▪ Provides an EC2-compliant web service interface.

▪ Walrus: AWS S3-compliant block storage system.

▪ Manages VM images, supporting bundling, uploading, registering, and

linking with kernel/ramdisk images.

o Key Feature: AWS compatibility, allowing tools and applications designed for AWS
EC2/S3 to be used with Eucalyptus.

2. Nimbus:

o Origin: Open-source toolkit.

o Goal: Provide IaaS by allowing clients to lease remote resources by deploying VMs.

o Architecture: (Figure 6.27 would show Cloud client, HTTP, Service node with Nimbus
IaaS and Cumulus storage, SSH, VMM node with Control, Libvirt, Xen/KVM, VMs, and
DHCP server).

▪ Nimbus Web: Python Django-based web interface for administration and

user functions.

▪ Cumulus: S3 REST API compatible storage cloud, extendable with features

like quota management.

▪ Resource Management: Supports "resource pool" mode (direct control of

VMs) and "pilot" mode (requests VMs from a cluster's LRMS).

▪ Implements Amazon's EC2 interface.

3. OpenNebula:

o Origin: Open-source toolkit.

o Goal: Transform existing infrastructure into an IaaS cloud with flexible and modular
integration capabilities.
 o Architecture: (Figure 6.28 would depict OpenNebula core, Scheduler, Drivers for
Virtualization/Network/Storage/External cloud, interfaces like Command-
line/Libvirt/Cloud interface, Local infrastructure, and External cloud).

▪ Core: Centralized component managing the full VM lifecycle, dynamic

network setup, and storage requirements.

▪ Capacity Manager/Scheduler: Governs resource allocation; default is

requirement/rank matchmaker, extendable for complex policies (leasing,
reservations).

▪ Access Drivers: Abstract underlying infrastructure (monitoring, storage,

virtualization) for uniform management.

▪ Interfaces: Libvirt API, command-line interface (CLI), and a cloud interface

for external users.

▪ Hybrid Cloud: Supports hybrid models using cloud drivers (e.g., EC2 driver)
to supplement local resources.

▪ Image Repository: Catalog for disk images, simplifying VM deployment.

4. Sector/Sphere:

o Goal: Support very large distributed data storage and simplified distributed data
processing.

o Architecture: (Figure 6.29 would show Security server, Master, Slaves, and Client,
with SSL and Data communication paths).

▪ Sector: A wide-area distributed file system (DFS).

▪ Uses UDP for message passing and UDT (User-defined Data

Transport Protocol) for high-speed data transfer.

▪ Aware of network topology for replica placement, enhancing

reliability and access.

▪ Client provides API, tools, and a FUSE user-space file system module.

▪ Sphere: A parallel data processing engine designed to work with data

managed by Sector.

▪ Supports UDFs running in parallel on input data segments,

leveraging data locality.

▪ Fault-tolerant (failed segments can be restarted).

▪ Components: Security server (authentication), Master servers (metadata,

job scheduling), Slave nodes (data storage/processing), Client.

▪ Space: A newer component for column-based distributed data tables.

5. OpenStack:

o Origin: Joint project by Rackspace and NASA (July 2010).

 o Goal: Build a massively scalable and secure open-source cloud infrastructure.

o Key Components:

▪ OpenStack Compute (Nova): IaaS fabric controller for managing large groups
of VMs. (Architecture detailed in question 8, Figure 6.30). Uses shared-
nothing, messaging-based architecture.

▪ OpenStack Object Storage (Swift): Software for creating redundant, scalable

object storage using clusters of commodity servers. Includes proxy server,
ring (mapping entities to physical locations), object/container/account
servers.

o Focuses on API compatibility (e.g., Amazon S3 for storage).

These environments are crucial for fostering competition, providing flexibility for users who want to
avoid vendor lock-in, and enabling research into new cloud architectures and management
techniques.

(Relevant OCR text: Module 5, Section 6.5)

5)

17. Describe the Manjrasoft Aneka cloud platform.

Manjrasoft Aneka is a cloud application platform designed to support the rapid development and
deployment of parallel and distributed applications. It can be deployed on private clouds (enterprise
resources), public clouds (like Amazon EC2), or hybrid combinations. Aneka aims to provide a flexible
and powerful environment for accelerating diverse workloads.

• Diagrams: Figure 6.31 (Architecture and components of Aneka, showing layers:

Infrastructure with .NET@Windows/Mono@Linux, Physical machines/virtual machines,
Private cloud/Data center; Fabric services with dynamic resource provisioning; Foundation
services like Membership, Reservation, Storage, License, Accounting; Container with
Programming models like Task, Thread, MapReduce; Application layer with Software
development kit (APIs, Design explorer) and Management kit (Management studio,
Administration portal, SLA-negotiation web services, Management web services). Also, side
components for Resistance and Security) and Figure 6.32 (Aneka using private cloud
resources along with dynamically leased public cloud resources, illustrating a hybrid cloud
scenario with client libraries, VPN, schedulers, executors on private enterprise network,
 public cloud like [Link], and a combined public cloud).

Key Capabilities and Features of Aneka:

1. Core Mission:

o Build: Provides an SDK with APIs and tools for rapid application development. Allows
building runtime environments for private, public, or hybrid clouds.

o Accelerate: Supports rapid development and deployment across multiple runtime

environments (Windows, Linux/UNIX via Mono). Aims for maximum utilization of
local resources and can dynamically lease public cloud resources (e.g., EC2) to meet
QoS parameters like deadlines.

o Manage: Offers management tools (GUI, APIs) to set up, monitor, manage, and
maintain Aneka compute clouds. Includes accounting and priority management
based on SLA/QoS.

2. Programming Models Supported:

o Thread Programming Model: Leverages multicore capabilities of nodes in a cloud.

o Task Programming Model: For quickly prototyping and implementing independent

"bag of tasks" applications.

o MapReduce Programming Model: For data-intensive parallel processing (as

discussed in Section 6.2.2).

3. Aneka Architecture (Layered):

o Aneka Container: A lightweight layer that interfaces with the hosting environment
(physical or virtual nodes) and manages deployed services.

o Platform Abstraction Layer (PAL): Mediates interaction with the hosting platform,
hiding OS heterogeneity. Handles infrastructure-related tasks like
performance/system monitoring, crucial for QoS.

o Service Categories (dynamically composable and extensible):

 ▪ Fabric Services: Fundamental operations of the cloud infrastructure.
Includes High Availability (HA) and failover, node membership/directory,
resource provisioning, performance monitoring, and hardware profiling.

▪ Foundation Services: Core middleware functionalities. Includes storage

management, resource reservation, reporting, accounting, billing, services
monitoring, and licensing. These operate across supported application
models.

▪ Application Services: Deal directly with application execution, providing the

appropriate runtime environment for each programming model. Leverage
fabric and foundation services for tasks like elastic scalability, data transfer,
performance monitoring, accounting, and billing. Each application model
generally has at least a scheduling service and an execution service.

4. Runtime Environment:

o Homogeneous distributed runtime built by aggregating physical and virtual nodes

hosting the Aneka container.

o Supports .NET on Windows and can run on Linux environments through Mono.

5. Deployment Flexibility:

o Can be deployed on a public cloud (e.g., Amazon EC2).

o Can form a private cloud using an organization's internal network of desktops and
servers.

o Can create a hybrid cloud by combining private cloud resources with dynamically
leased public cloud resources.

6. Virtual Appliances:

o Aneka can integrate VMs and P2P network virtualization into self-configuring,
prepackaged "virtual appliances."

o These appliances contain the entire software stack (OS, libraries, Aneka) for easy
deployment of homogeneously configured virtual clusters across heterogeneous,
wide-area systems.

Use Case Example - Maya Rendering (Figure 6.33):

• GoFront Group used Aneka to create an enterprise cloud from networked PCs to accelerate
3D rendering of engineering designs using Autodesk Maya.

• Aneka Design Explorer was used for parameter sweep (rendering different images/camera
angles).

• Reduced rendering time for 2000+ frames from 3 days (on a single four-core server) to 3
hours (on a 20-node Aneka cloud).

Aneka provides a comprehensive platform for developing, deploying, and managing distributed
applications, emphasizing flexibility in programming models, runtime environments, and cloud
deployment types (private, public, hybrid).
(Relevant OCR text: Module 5, Section 6.5.3)

18. InterCloud resource management.

InterCloud resource management refers to the strategies, architectures, and mechanisms for
managing and exchanging resources between different cloud environments. This becomes crucial as
organizations adopt hybrid cloud models or need to leverage services from multiple public cloud
providers.

Key Aspects and Challenges of InterCloud Resource Management:

1. Extended Cloud Computing Services Layers:

o Diagram: Figure 4.23 (A stack of six layers of cloud services and their providers:
HaaS, NaaS, LaaS/Security-aaS, IaaS/DaaS/CaaS, PaaS, SaaS) is foundational to
understanding what resources might be managed across clouds.

o InterCloud management can occur at any of these layers, from basic

hardware/network provisioning to complex application-level service integration.

2. Cloud Service Tasks and Trends:

o Vertical Cloud Services: Sequences of mutually supportive cloud services. InterCloud

management may involve orchestrating these vertical stacks across different
providers. (Figure 4.25 in Module 3 would illustrate this).

o Cloud Mashups: Combining services from multiple clouds simultaneously or

sequentially (e.g., an industrial supply chain using different cloud resources at
different stages). This requires robust InterCloud resource discovery and integration.

3. Resource Provisioning Across Clouds:

o Compute Resources (VMs):

▪ Dynamically provisioning VMs from external clouds when local resources are
insufficient (bursting to the cloud).
 ▪ Requires common VM formats (like OVF - Open Virtualization Format) for
portability and interoperability between different cloud platforms.

▪ Live migration of VMs between private and public clouds, or between

different public clouds, is a complex InterCloud management challenge.

o Storage Resources:

▪ Accessing and synchronizing data stored in different clouds.

▪ Strategies for data placement and movement to minimize latency and cost.

o Network Resources:

▪ Establishing secure and efficient network connections (e.g., VPNs) between

different cloud environments.

▪ Managing IP addressing and routing across cloud boundaries.

4. Federated Clouds and Brokering:

o Cloud Federation: An aggregation of multiple independent cloud providers that pool

their resources and offer them as a unified service. This requires sophisticated
InterCloud schedulers and resource brokers.

o Cloud Brokers: Intermediaries that select and manage resources from multiple cloud
providers on behalf of users, often based on cost, QoS, or specific capabilities.
(Figure 4.26 in Module 3 depicts a cloud broker architecture).

5. Standardization and Interoperability:

o Lack of Standard APIs: Proprietary APIs hinder seamless resource management

across different clouds. Standardized APIs are needed for true InterCloud
interoperability.

o OVF: An important step towards standardizing VM packaging and distribution for

cross-platform deployment.

o Need for hypervisor-agnostic VMs and cross-platform live migration (e.g., between
x86 Intel and AMD).

6. Security and Trust Management in InterCloud Scenarios:

o Managing trust relationships between different cloud providers and between users
and multiple providers.

o Ensuring consistent security policies and data protection across federated or

brokered cloud environments.

o Securely managing credentials and access control when resources are distributed.

o Reputation systems for cloud providers become even more important in an

InterCloud ecosystem. (Figure 4.37 in Module 3 shows DHT-based trust overlay
networks).

7. SLA Management:
 o Negotiating and monitoring SLAs when services span multiple cloud providers.

o Attributing responsibility and penalties when SLAs are violated in a multi-cloud

deployment.

InterCloud resource management is essential for realizing the full potential of cloud computing,
enabling greater flexibility, resilience, cost optimization, and avoidance of vendor lock-in. However, it
also introduces significant technical and administrative challenges that require ongoing research and
standardization efforts.

(Relevant OCR text: Module 3, Sections 4.5, [Link], [Link], [Link])

19. GAE, AWS, Azure.

Google App Engine (GAE), Amazon Web Services (AWS), and Microsoft Azure are three major public
cloud platforms, each with distinct characteristics, service models, and target use cases.

• Diagrams: Figure 4.20 (Google cloud platform/GAE major building blocks), Figure 4.21
(Amazon cloud computing infrastructure/AWS key services), Figure 4.22 (Microsoft Windows
Azure platform for cloud computing). Table 4.5 (Five Major Cloud Platforms and Their Service
Offerings) provides a good comparative overview.

I. Google App Engine (GAE):

• Service Model: Primarily Platform-as-a-Service (PaaS).

• Focus: Designed for building and hosting scalable web applications. It abstracts away much
of the infrastructure management.

• Programming Languages: Python, Java (and other JVM languages).

• Key Services/Features:

o Datastore: NoSQL database based on BigTable for structured data.

o Blobstore: For large binary objects.

o Memcache: In-memory caching.

o Automatic scaling, load balancing.

o Integrated services: Mail, Users (Google Accounts), Images, Cron, Task Queues.

o Relies on Google's proprietary infrastructure like GFS, BigTable, Chubby.

• Strengths: Highly scalable, simplified development for web apps, robust integrated services,
free tier for small applications.

• Limitations: More restrictive programming model compared to IaaS, limited language

support, "sandbox" environment imposes some restrictions.

II. Amazon Web Services (AWS):

• Service Model: Primarily Infrastructure-as-a-Service (IaaS), but with a growing number of

PaaS and SaaS offerings.
 • Focus: Provides a broad and deep set of fundamental building blocks for computing, storage,
networking, databases, analytics, machine learning, IoT, and more. Offers high flexibility and
control.

• Key Services/Features (a small subset):

o EC2 (Elastic Compute Cloud): Virtual servers (VM instances) with various OS options.

o S3 (Simple Storage Service): Highly scalable object storage.

o EBS (Elastic Block Store): Persistent block storage for EC2 instances.

o RDS (Relational Database Service): Managed relational databases (MySQL,

PostgreSQL, Oracle, SQL Server, Aurora).

o SimpleDB/DynamoDB: NoSQL databases.

o Elastic MapReduce (EMR): Managed Hadoop framework.

o SQS (Simple Queue Service), SNS (Simple Notification Service): Messaging services.

o VPC (Virtual Private Cloud): Isolated network environments.

o Auto Scaling, Elastic Load Balancing, CloudWatch (monitoring).

• Strengths: Most mature public cloud, widest range of services, extensive global
infrastructure, strong ecosystem, high flexibility for developers.

• Limitations: Can have a steeper learning curve due to the vast number of services, cost
management can be complex.

III. Microsoft Azure:

• Service Model: Offers both PaaS and IaaS, with a strong integration with Microsoft's existing
enterprise software and development tools.

• Focus: Provides a comprehensive platform for building, deploying, and managing

applications and services through Microsoft-managed data centers.

• Key Services/Features (a small subset):

o Azure Virtual Machines: IaaS for Windows and Linux VMs.

o Azure App Service (Web Apps, Mobile Apps, API Apps, Logic Apps): PaaS for
building web and mobile applications.

o Azure SQL Database: Managed relational database service.

o Cosmos DB: Globally distributed, multi-model NoSQL database.

o Azure Storage (Blobs, Tables, Queues, Files, Disks): Scalable storage services.

o Azure Functions: Serverless compute.

o Azure Active Directory: Identity and access management.

o Integration with .NET, Visual Studio, and other Microsoft technologies.

o Service Fabric: Platform for building microservices.

 o Roles (Web Role, Worker Role): PaaS compute concepts for web frontends and
background processing.

• Strengths: Strong integration with Microsoft ecosystem, good for hybrid cloud scenarios,
comprehensive PaaS and IaaS offerings, enterprise-focused.

• Limitations: Historically, might have been perceived as more Windows-centric, though Linux
support is now extensive.

Comparison Summary (based on Table 4.5 and general text):

Feature GAE (Google) AWS (Amazon) Azure (Microsoft)

Primary IaaS (expanding to

PaaS PaaS & IaaS
Model PaaS/SaaS)

Application
Virtualization OS & Xen (for EC2) OS level / Hyper-V
Container

Azure Storage (Blobs,

Datastore S3, EBS, SimpleDB,
Key Storage Tables), SQL Azure, Cosmos
(BigTable), GFS RDS, DynamoDB
DB

App Engine VMs, Web/Worker Roles,

Compute EC2 Instances
Instances Functions

Data MapReduce Elastic MapReduce HDInsight (Hadoop), Data

Processing (internal) (Hadoop) Lake Analytics

Web Admin EC2 Command-Line,

User Interface Azure Portal, PowerShell, CLI
Console Web Console

Web App Developers needing Enterprise & .NET

Target User
Developers infrastructure Developers

All three platforms offer robust solutions for various cloud computing needs, with continuous
evolution and expansion of their service portfolios. The choice often depends on specific application
requirements, existing technology stacks, desired level of control, and pricing considerations.

18. InterCloud resource management. (Revised 10-Mark Answer - aiming for better balance)

InterCloud resource management refers to the strategies and mechanisms for coordinating and
utilizing resources across multiple, distinct cloud environments. It is essential for enabling hybrid
clouds and leveraging specialized services from different providers, but presents significant
challenges in interoperability, security, and management.

Core Concepts and Layers:

The scope of InterCloud management is best understood through the extended cloud computing
service layers (Figure 4.23):

1. Foundational Layers (HaaS, NaaS, LaaS): At the base, InterCloud management involves
coordinating physical hardware (HaaS), network connectivity (NaaS, e.g., extending Virtual
LANs across providers like AT&T), and secure colocation facilities (LaaS, e.g., Savvis). This
requires managing physical security and basic infrastructure across potentially different
ownership domains.J

2. Infrastructure Services (IaaS, DaaS, CaaS): This involves provisioning and integrating
compute, data, and communication services from diverse IaaS providers (e.g., AWS, Azure).
Key challenges include managing resource allocation, data synchronization, and ensuring
consistent performance when infrastructure components are sourced from multiple clouds.

3. Platform and Application Services (PaaS, SaaS): Managing resources at these higher layers
across clouds is complex. It involves deploying SaaS applications (e.g., Salesforce CRM) onto
PaaS environments (e.g., Google App Engine) which may, in turn, rely on IaaS from yet other
providers. This demands application portability, data integration across platform APIs, and
consistent user experience.

Key Considerations and Challenges:

• Varying Cloud Player Perspectives (Table 4.7): Different stakeholders (IT administrators,
developers, end-users) have distinct roles and concerns when dealing with IaaS, PaaS, or
SaaS resources spread across clouds. For example, developers need robust APIs for platform
integration, while administrators focus on SLA monitoring across providers.

• Service Trends Driving InterCloud Needs:

o Vertical Cloud Services: Sequences of interdependent services (e.g., a manufacturing

supply chain using services from different specialized clouds) require sophisticated
InterCloud orchestration.

o Cloud Mashups: Combining functionalities from various cloud applications (e.g.,

integrating a mapping service from Cloud A with an e-commerce platform from
Cloud B) necessitates robust resource discovery and data exchange mechanisms
between clouds.

• Software Stack and Runtime Interoperability:

o The underlying software stacks (OS, file systems, databases) and runtime support
services (monitoring, scheduling, e.g., for MapReduce) in different clouds often lack
inherent compatibility.

o This necessitates strategies for federation, brokerage, or the development of

standardized interfaces to enable seamless InterCloud operations and data
management.

• Security and Trust: Managing security policies, data privacy, and trust relationships across
multiple autonomous cloud providers is a critical and complex aspect of InterCloud resource
management.
In essence, InterCloud resource management aims to create a cohesive and efficient operational
environment from disparate cloud services, addressing challenges of heterogeneity, control, and
security to realize benefits like flexibility and optimized cost/performance.