A Fault Tolerant Virtualization Server Based on Xen...A Fault Tolerant Virtualization Server Based...
Transcript of A Fault Tolerant Virtualization Server Based on Xen...A Fault Tolerant Virtualization Server Based...
A Fault Tolerant VirtualizationServer Based on Xen
Jürgen GroßVirtualization Kernel Developer
SUSE Linux GmbH, [email protected]
Status Quo
3
Standard Xen Virtualization Server
SANLAN
dom0
Hypervisor
HVM pv
xenstore qemuBlock-
backendNet-
backend
4
Single Points of Failure in Xen Server
• Hypervisor
• Dom0
• Xenstore
• pv-Backends
• LAN/SAN peripherals in case of single path
5
Standard Xen Virtualization Server
SANLAN
dom0
Hypervisor
HVM pv
xenstore qemuBlock-
backendNet-
backend
6
Kinds of Failures
• Software errors (crashes, hangups)
• Fatal Hardware errors
• Non-fatal Hardware errors triggering software errors
• Planned downtimes due to software updates
• Planned downtimes due to hardware maintenance
Eliminating Single Points of Failure
8
Xen Server Today
SANLAN
dom0
Hypervisor
HVM pv
xenstore qemuBlock-
backendNet-
backend
9
Use Multipathing
• LAN and SAN resources still accessible in case of path failure
• Dom0 does multipathing for domUs
10
Use Multipathing
SANLAN
dom0
Hypervisor
HVM pv
xenstore qemuBlock-
backendNet-
backend
11
Move Xenstore Into Own Domain
• Mandatory step for eliminating dom0 being single point of failure
• Xenstore is still single point of failure, but dom0 high load won't slow it down any more
12
Move Xenstore Into Own Domain
SANLAN
dom0
Hypervisor
HVM pvxenstore
qemuBlock-
backendNet-
backend
13
Create Driver Domains
• LAN‒ One per interface card
‒ Multipathing done in guests
‒ Net-backend no longer single point of failure
‒ Driver domain can act as a managed switch
• Block‒ Multipathing still done in backend
‒ Further decoupling from dom0
14
Create Driver DomainsLAN: one per interface adapter
SANLAN
dom0
Hypervisor
HVM pvxenstore
qemu
Net-back
Block-back
Net-back
15
Introduce pv-SAN Backend
• Now one driver domain per interface card
• Multipathing done in guests
• Block-backend no longer a single point of failure
• In case of SAN topology aware guests PCI-passthrough of FC-cards to guest no longer necessary
• Driver domain acts as a SAN switch
16
Introduce pv-SAN Backendone per interface adapter
SANLAN
dom0
Hypervisor
HVM pvxenstore
qemu
SAN-back
Net-back
SAN-back
Net-back
17
Use Stub Domains for HVM domUs
SANLAN
dom0
Hypervisor
HVM pvxenstore stub
qemu
SAN-back
Net-back
SAN-back
Net-back
18
Make dom0 Restartable
SANLAN
dom0
Hypervisor
HVM pvxenstore stub
qemu
SAN-back
Net-back
SAN-back
Net-back
How to Reach This Goal?
20
TODO: Verification, Configuration
• Xenstore domain
• LAN driver domain
• Block driver domain
• Stub domains for HVM
21
TODO: Implementation
• Dom0 restart
• SAN pv backend
• Tooling for automatic creation of driver domains for each interface card
• Tooling for automatic restart of crashed infrastructure domains (dom0, driver domains)
• Support for software updates of infrastructure domains
• Support for hotplug of interface cards
• Support for live migration
Thank you.
22
Who is interested?
SUSE: ✔
23