a fault tolerant virtualization server based on xen
play

A Fault Tolerant Virtualization Server Based on Xen Jrgen Gro - PowerPoint PPT Presentation

A Fault Tolerant Virtualization Server Based on Xen Jrgen Gro Virtualization Kernel Developer SUSE Linux GmbH, jgross@suse.com Status Quo Standard Xen Virtualization Server dom0 HVM pv Net- Block- xenstore qemu backend backend


  1. A Fault Tolerant Virtualization Server Based on Xen Jürgen Groß Virtualization Kernel Developer SUSE Linux GmbH, jgross@suse.com

  2. Status Quo

  3. Standard Xen Virtualization Server dom0 HVM pv Net- Block- xenstore qemu backend backend Hypervisor SAN LAN 3

  4. Single Points of Failure in Xen Server • Hypervisor • Dom0 • Xenstore • pv-Backends • LAN/SAN peripherals in case of single path 4

  5. Standard Xen Virtualization Server dom0 HVM pv Net- Block- xenstore qemu backend backend Hypervisor SAN LAN 5

  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 6

  7. Eliminating Single Points of Failure

  8. Xen Server Today dom0 HVM pv Net- Block- xenstore qemu backend backend Hypervisor SAN LAN 8

  9. Use Multipathing • LAN and SAN resources still accessible in case of path failure • Dom0 does multipathing for domUs 9

  10. Use Multipathing dom0 HVM pv Net- Block- xenstore qemu backend backend Hypervisor SAN LAN 10

  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 11

  12. Move Xenstore Into Own Domain dom0 xenstore HVM pv Net- Block- qemu backend backend Hypervisor SAN LAN 12

  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 13

  14. Create Driver Domains LAN: one per interface adapter dom0 Net- Net- Block- xenstore HVM pv back back back qemu Hypervisor SAN LAN 14

  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 15

  16. Introduce pv-SAN Backend one per interface adapter dom0 Net- Net- SAN- SAN- xenstore HVM pv back back back back qemu Hypervisor SAN LAN 16

  17. Use Stub Domains for HVM domUs dom0 Net- Net- SAN- SAN- xenstore stub HVM pv back back back back qemu Hypervisor SAN LAN 17

  18. Make dom0 Restartable dom0 Net- Net- SAN- SAN- xenstore stub HVM pv back back back back qemu Hypervisor SAN LAN 18

  19. How to Reach This Goal?

  20. TODO: Verification, Configuration • Xenstore domain • LAN driver domain • Block driver domain • Stub domains for HVM 20

  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 21

  22. Who is interested? SUSE: ✔ Thank you. 22

  23. 23

Recommend


More recommend