1 / 22

Implementing Dual-Boot Clusters in a Distributed Environment

Implementing Dual-Boot Clusters in a Distributed Environment. Surajit Bose, Technology Services Manager Dustin King, Systems Imaging Architect. Our Environment. Not central IT Over 100 computer clusters, mostly unstaffed Dorms, Row Houses, Graduate Residences Central and Branch Libraries

jeri
Download Presentation

Implementing Dual-Boot Clusters in a Distributed Environment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing Dual-Boot Clusters in a Distributed Environment • Surajit Bose, Technology Services Manager • Dustin King, Systems Imaging Architect

  2. Our Environment • Not central IT • Over 100 computer clusters, mostly unstaffed • Dorms, Row Houses, Graduate Residences • Central and Branch Libraries • Student Centers • Most open 24/7 • Approximately 500 cluster machines • Historically, even mix of Dells and Apples

  3. Our Prior Infrastructure • Campus-wide Kerberos authentication • PXE/Ghost for Windows imaging • Windows machines joined to AD • Domain scripts for Windows maintenance • NetRestore for Mac imaging • Macs bound to LDAP • Radmind for Mac maintenance • Linux server environment

  4. Why Dual-Boot? • Bypass question of optimal platform mix • Improve availability of single-platform software • Provide choice for students • Homogenize inventory • Seemed like a cool thing to try

  5. Desiderata • Network-based full-disk imaging • Platform parity • Manage each platform independently • Ease of switching OS • Non-ridiculous login times • Server-side control • Consistent imaging process across hardware • Shared local storage across OSes

  6. What We Discovered • Managing the reboot cycle is difficult • Existing solutions unsatisfactory for us • BootPicker, NetRestore/WinClone Mac-centric • rEFIt makes management difficult • No network boot environment works for both Dell and Apple machines • Partition order matters

  7. What We Decided • Control boot process with EFI shell environment (SCUBA) • Inter-OS communication via locally stored state file • NetBoot install environment (Genie) • Use convoluted partition scheme • Use Paragon NTFS and MacDrive • Use customized login screens • Nightly maintenance reboots • Server-side tracking of machine state

  8. EFI Shell Environment • Boot to EFI shell • Fits on a flash drive for full-disk imaging • Shell modified to ignore keyboard interrupts • EFI toolkit has network stack, http client, Python • Startup script • validates nvram boot options • checks with server • reads and updates local state file • sets nextboot value in nvram

  9. Priority of Boot Flags • Required (from server) • Mac Maintenance (from local state file, set by script) • Windows Maintenance (from local state file, set by script) • Requested (from local state file, set by user) • Suggested (from server)

  10. Local State File • Houses maintenance and requested boot flags • Caches most recent response from the server • Has to be writable from both OSes as well as EFI shell environment

  11. Genie • Based on NetInstall set built with Mac OS X Server Admin Tools • Bash scripts check server for configuration and manage imaging process • Report progress through iHook

  12. Windows Login Screen (pGina)

  13. Mac Login Screen (SCUBA)

  14. Partition Scheme • EFI System Partition: leave alone per Apple recommendation • FAT: store Windows images and local state file • NTFS: local storage space for users • NTFS: Windows system partition • HFS+: EFI shell environment • HFS+: Mac system partition

  15. Handling Partitions • Mac OS X • Paragon NTFS • Remount volumes under /Library/Mounts • Windows XP • MacDrive • Some partitions already invisible • Remount volumes under c:\stucomp\mnt

  16. Nightly Maintenance • Scripts on each OS write maintenance flags into state file • Windows • Python reboot service • Domain startup scripts • Mac • Radmind • iHook

  17. Server-Side Setup • Genie • Background downloads • SCUBA flags • Printer configuration • Imaging request page • Status “database”

  18. Gotchas • Per-seat licensing costs • Mouse and keyboard confusion • NetBoot memory management horror • Windows reboot behavior • Time and Kerberos logins • Permissions on shared volumes • SSH keys

  19. Planned Enhancements • Improve build processes for EFI, NetBoot environments • Increase structural similarity of configuration and management between platforms • Implement PKI for client-server communications • Explore emerging solutions (e.g. XHooks) • Implement cross-platform monitoring system • Reduce power usage on clients • Create documentation • Release as open-source

  20. Acknowledgments • Karl Kuehn, Software Image Developer • Alex Schorsch, Student Developer • Fangling Zhang, Student Developer • Paul Nuyujukian, Student Developer • Ian Comfort, Systems Administrator

  21. Questions?

  22. Thanks!surajit@stanford.edudaking@stanford.edu_________Evaluate!http://www.resnetsymposium.org/rspm/evaluation/Thanks!surajit@stanford.edudaking@stanford.edu_________Evaluate!http://www.resnetsymposium.org/rspm/evaluation/

More Related