Lecture 18: Cloud operating systems
Exam
From virtualization to the Cloud and its OS approaches
Important questions:
- Which service models exist for Cloud systems?
- What are their properties, pros and cons?
- Which provisioning models exist?
- What does the architecture for a Cloud OS look like?
- What are differences to a "regular" OS?
- Which strategic decisions have to be taken by a Cloud OS?
- What is a container and how are containers related to virtualization?
- What is virtualized in containers?
- How does virtual memory management interact with virtualization for the Cloud?
- Which optimization approaches exist, can you describe them?
- How can I/O be virtualized for the Cloud?
- Which I/O virtualization approaches exist, can you name pros/cons?
Cloud computing
- According to the US National Institute of Standards and Technology, a Cloud has five properties:
Hardware virtualization
- β¦enables the creation of multiple virtual machines on one physical computer. Each virtual machine can have its own OS.
- Important foundation technology for Cloud computing and server consolidation
- Technical basis: hypervisor / virtual machine monitor Application processes of the host OS Application processes of the guest OSβs
Cloud service models
- SaaS β Software-as-a-Service
- Cloud service provider offers a complete application
- e.g. Office365, Gmail, Zoom
- PaaS β Platform-as-a-Service
- Execution environment for applications including the OS and runtime environment (depending on the programming language)
- e.g. Engine Yard, Google App Engine
- IaaS β Infrastructure-as-a-Service
- (Virtual) hardware platform
- e.g. Amazon EC2, Microsoft Azure
Discussion: Cloud disadvantages
- Cloud-Computing has a number of advantages, but can also cause problems that must not be ignoredβ¦
- Data protection and privacy
- Where are the data of my users/customers located? Which data protection laws apply in the respective country? (β GDPR)
- Is the cloud service provider trustworthy?
- Vendor lock-in
- Can I retrieve my data (for a reasonable amount of money) if I want to change the provider? If yes, in which format?
- Quality of service
- Which guarantees are offered by the provider?
- Data protection and privacy
Provisioning models
- Public Cloud
- Cloud Service Provider (CSP) has arbitrary customers
- Private Cloud
- A cloud infrastructure for a (large) company, which can use the companyβs own or rented resources. β more control
- Community Cloud
- Multiple customers with the same requirements share a cloud infrastructure
- Hybrid Cloud
- Mixed approach
Comparison of provisioning models
- Stallings: "Operating Systems: Internals and Design Principles"
Application example / Requirements
General architecture of a cloud OS
- All resources are virtualized β IaaS is basis of all services
Strategic decisions
- Where to place the VMs? When should they be migrated?
- How to minimize SLA violations? How much overbooking?
- Does it make sense to release and switch off single computers? Different strategies are possible:
Example: OpenStack
- Open source cloud OS: www.openstack.org
Relevance and use of virtualization
- Enforces strict adherence to a layer structure through control and intervention possibilities for resource accesses by a VM
- Basis for...
- This construction principle can be replicated on different layers and for different resources
Container base virtualization
or simply containers
- The OS kernel is virtualized
- Containers share a kernel
- Libraries and system processes can be different
- The virtualization component takes care of...
- Separate views, e.g. each container sees only its "own" processes
- Resource partitioning, e.g. CPU time
- Efficient sharing, e.g. avoid duplication of files
Example: Linux container support
- Integrated in the Linux kernel
- Container solutions only provide management tasks
- Separate views: Name spaces per task
- β¦for computer names ("UTS"), processes ("PID"), mount points ("mount"), network devices and configuration ("network"), IPC objects ("IPC"), control groups ("Cgroup") and system time ("Time")
- Resource partitioning: Control groups (cgroups)
- Container shares of CPU time, memory and I/O bandwidth
- Configuration interface: pseudo file system cgroupfs
- Efficient sharing (of files): Overlay FS
- Overlay of directory trees
Hardware virtualization
- A complete computer (CPU, memory, I/O devices) is virtualized:
CPU virtualization (1)
- Most simple approach: CPU emulation (+ multiplexing)
- Interpretation or Just-in-time translation (JIT) of the instructions of the emulated processor
- Examples: Bochs, QEMU, MAME
- Imitates an arbitrary CPU Y with the help of a CPU X
- Problem: slow execution speed
FAST/SLOW: with/without code optimization
static int foo(int i) {
return(i+1);
} int main(void) {
β¦ <start timer>
for(i=0; i<100000000; i++)
t += foo(i);
β¦ <stop timer>
}
Conclusion: avoid CPU emulation where possible
CPU virtualization (2)
- Efficient approach: CPU multiplexing (CPU X1 , β¦, XN on X)
- Desired properties ("virtualization criteria")
- Equivalence: a VM behaves identical to the real machine
- Security: a VM is isolated. The hypervisor has full control
- Performance: virtual CPUs are not significantly slower than the real one
- Question: which architectures are "virtualizable" in this way?
- Answer (Popek and Goldberg, 1974 [3]):
- CPUs have "sensitive" instructions which depend on the privileged mode of the CPU (user/supervisor mode, memory mapping, β¦) or switch its mode
- All sensitive instructions must generate a trap when executed in user mode. This allows the hypervisor to emulate the instruction
- The "rest" works like a regular OS: VM scheduling
Memory virtualization (1)
- Problem: additional memory mapping layer
Guest operating systems assume that they have complete control over the hardware. They use arbitrary page frames. Without the additional mapping layer, conflicts with other guest OSes could occur!
Memory virtualization (2)
- Solution 1: Shadow page tables
- Require no special hardware virtualization support
- Idea:
- Do not use the guest OS page tables
- Hypervisor keeps a shadow page table for each guest page table
- Shadow table must be kept up to date!
- Version 1: intercept and interpret all accesses to memory which stores part of a page table
- Version 2: ignore changes, update tables when a page fault occurs
- Both variants result in many traps to the hypervisor β overhead
Shadow page tables are expensive. Lower costs are possible using paravirtualization or hardware support
Memory virtualization (3)
- Solution 2: Nested page tables (AMD; Intel: "extended page tables"
- Idea:
- Hardware is responsible for the complete memory mapping
- Guest OS can change "its" page table as required
- Page table walk is more expensive β greater relevance of the TLB
- Page tables have tree structure
- Pointers to tables are physical guest addresses
- Translation to physical host addresses required (here: 4 translations!)
Memory virtualization (4)
More approaches...
- Ballooning: "Trick" for dynamic allocation of memory to VMs
- Small driver module communicates with the hypervisor
- Can reserve memory of the OS kernel on demand
- This memory can then be distributed to other VMs
- Deduplication: Detection and avoidance of duplicate page contents between VMs. Saves main memory, e.g. between identical guest OSes
- VM migration
- Complete memory contents of a VM moved to other host system
- Optimization: Transfer of pages while the VM is running
- Recent changes are monitored using the dirty bit in the page table
- VM replication
- Memory state changes are periodically transmitted to a backup host. Backup VM can replace one on a crashed/failed system quickly
I/O virtualization (1)
- Simple approach: I/O emulation (+ multiplexing)
- Accesses to I/O device registers are privileged operations or can be intercepted by the hypervisor using the MMU ("trap and emulate")
- Emulation of arbitrary I/O devices Y using I/O device X
- e.g. in Oracle VirtualBox: PS/2 mouse/keyboard; IDE, SATA, SCSI, β¦ hard disk; SVGA graphics card; different AMD and Intel network controllers; USB host controller; ACβ97, Intel HD or Soundblaster 16 sound cards
- Problem: I/O throughput
- Even simple I/O operations require hundreds or thousands of I/O register accesses!
I/O emulation is expensive. Lower costs are (again) possible using paravirtualization or hardware support
I/O virtualization (2)
- Alternative: do not use multiplexing β device passthrough
- A device is exclusively assigned to exactly one VM
- Arbitrary register accesses are permitted (without causing a trap)
- Problems:
- DMA addresses are physical host addresses not known to the VM
- This could be used to violate the VM isolation
- Interrupts could be triggered on the "wrong" CPU
- Solution: I/O MMU
- Hardware extension implemented in CPU or mainboard chip set
- DMA uses an address mapping using tables
- Acceleration using separate TLBs
- Interrupt remapping is able to change the interrupt number and destination CPU
I/O virtualization (3)
- Alternative 2: PCIe single root I/O virtualization (SR-IOV)
- Hardware mechanism: One device appears as multiple virtual ones
- Multiple I/O register sets, multiple interrupt configurations, β¦
- Hypervisor maps one of these devices to a VM and does not have to interfere further
- Possible problem:
- Hardware takes care of the prioritization of VMs itself
- e.g. round robin
- Conflicts with priorities of the hypervisor are possible
- Hardware takes care of the prioritization of VMs itself
Conclusion
- Virtualization is an important architectural concept recurring in the system software stack
- Transparent: Multiplexing, aggregation, emulation
- Hardware virtualization (according to Popek/Goldberg)
- Replaces inflexible connection of hardware and software
- enables e.g. migration and replication of VMs at runtime
- Technical basis for cloud computing
- Replaces inflexible connection of hardware and software
- Operating systems for clouds
- Well-known functionality: Resource management and abstractions
- β¦implemented on a higher layer