Repositories for Partition Cloning

Transcription

1 Repositories for Partition Cloning OS Independent Software Maintenance in Large Clusters of PCs Felix Rauch Christian Kurmann, Thomas M. Stricker Laboratory for Computer Systems, ETH Zürich CoPs Project: Eidgenössische Technische Hochschule Zürich 1. December

2 Clusters of PCs Scientific computing (simulations / protein folding) Enterprise computing (distrib. databases / datamining) Corporate computing (multimedia / collaborative work) Education and training (classrooms) 2

3 Problem Software Maintenance Need guarantee of functioning software environment on all nodes Often software MTBF is inacceptable due to software rot Administration of large numbers of nodes (efficiency) Administration of different OS and different versions (flexibility) 3

4 Our Approach Work with whole partitions as abstraction units (partition = large amount of bits on hard disk) Use cloning for replication Clean abstraction of software state in cluster node No file system dependency No operating system dependency No dependency on registry databases and shared configuration files Maintenance system based on snapshots This approach needs an efficient storage system 4

5 Overview Characteristics of software installations Related work Partition Repositories Evaluation Conclusions 5

6 Evolution and Replication of Software Installations Software installations change continually. Abstraction along two axes: Temporal Spacial Time Space 6

7 Temporal Evolution of a Software Installation Installation of new software Upgrading software packages Patches Temporary installations Snapshot after every change to recover from failing installations or deinstallations 7

8 Spacial Evolution of a Software Installation Replication across hundreds of nodes Localization (IP-number, default printer, drivers, licence files, user preferences, etc.) Snapshot of every node to recover from node failure or failing local change to installation 8

9 Characteristics of Installation and Maintenance Time Initial OS installation Space 9

10 Characteristics of Installation and Maintenance Time Initial OS installation Service pack / patch Space 10

11 Characteristics of Installation and Maintenance Time Initial OS installation Service pack / patch Temporary installation Space 11

12 Characteristics of Installation and Maintenance Time Initial OS installation Service pack / patch Temporary installation Addition of new software packages Space 12

13 Characteristics of Installation and Maintenance Time Initial OS installation Service pack / patch Temporary installation Localized replication Addition of new software packages Space 13

14 Characteristics of Installation and Maintenance Time Initial OS installation Service pack / patch Temporary installation Localized replication Addition of new software packages Personalized replication Localized replication Space 14

15 Why an OS Independent Framework? Simplest approach No knowledge about file system required No knowledge about operating system required But working with partitions is a storage nightmare! Contribution: Solution of storage problem with block repositories 15

16 Related Work Cloning tool for efficient partition distribution: Dolly [Rauch, Kurmann, Stricker; EuroPar 2000] Comparison of backup speed for logical and physical backups [Hutchinson et al; OSDI 99]. Use different terminology: OS independent archive files (tar), not OS independent tools. Commercial tools such as Norton Ghost, Image Cast or DriveImage Pro: Either efficient or OS independent, but not both. Approaches by system administrators at LISA conferences: Either archive whole partitions or use file system dependent tools. 16

17 Archival Techniques Our solution: Works with raw disk/partition data Requires no knowledge about file system Prerequisite: Maintenance OS (e.g. small Linux). Three different archival techniques: Full (compressed) partition images on file server Blockwise diffs Block repositories 17

18 Full Partition Images A B C D B E A F C E B G 6 blocks + 6 blocks = 12 blocks of storage required 18

19 Full Partition Images A B C D B E A F C E B G 6 blocks + 6 blocks = 12 blocks of storage required Partition stored in file Compressed with gzip Very easy to implement A lot of diskspace wasted as two consecutive images are mostly identical 19

20 Blockwise Diffs A B C D B E A F C E B G 6 blocks + 3 blocks = 9 blocks of storage required First partition fully archived For subsequent installations only differences archived Disk blocks at same places on disks are compared Only changed blocks are stored in archive 20

21 Shortcomings of Blockwise Diffs Blockwise diffs still miss some identical blocks: Identical blocks in the same partition Removal and reinstallation results in moved blocks Defragmentation of file system moves blocks around Log structured file systems frequently move blocks around to regain empty segments 21

22 Block Repositories A B C D B E A F C E B G 5 blocks + 2 blocks = 7 blocks of storage required All blocks are compared to each other First partition is compared and inserted in same way Only unique blocks are inserted in the repository For all other blocks, pointers to existing identical blocks are inserted in the repository 22

23 Properties of Block Repositories + Captures all block movements - Effort to compare all blocks Obvious complexity at the first sight: O(n 2 ) In practice: Comparison of two 2 GB partitions takes only 7 minutes on high end PC. Use hash-function to speed up comparison: cn+o(n) Done only once for each partition Can be done as batch job during the night - Complex implementation 23

24 Implementations Production system still uses full partition images. Based shell scripts and NFS to archive and distribute partitions. Available under Open Source licence. Small research prototype implemented in C does comparisons for blockwise diffs and block repository approaches. Research prototype is used for evaluation. Not yet available for distribution. 24

25 Evaluation Measurements with production images of various systems (Linux, Windows NT, Oberon). Compare different archive techniques: Full partition images Blockwise diffs Block repositories Compare different administrative tasks: General update / upgrade of existing system Localization / personalization Installation of new software 25

26 Archive Techniques Oberon Upgrade and Driver Change (no gzip compression) Size [MBytes] Full image Blockwise diffs Block repository Method of storage Initial Installation New OS version Hardware adaption 26

27 Same Application on Two Systems Star Office in Block Repository, no gzip compression Size [MBytes] Original Repository Increase after StarOffice Installation Windows NT Linux 27

28 Localized Partitions in Block Repository Localization based on replication, no gzip compression Size [MBytes] localized installations Partition Size Block Repository with one partition 27 Increase for one localized partition Full Block Repository 28

29 Archive Techniques with Compression Successive Windows NT installation, 2 GB partition Size [MBytes] Compressed Images Compressed Diffs Compressed Repository Method of storage Base Install Small upgrade Service pack 29

30 Tradeoff: Repositories vs. Compression Using large block size for repository results in: Coarser difference detection Larger repository Better compression ratio Smaller repository Which is block size for best results? 30

31 Influence of Block Size on Archive Size Size of repository/image [MByte] K 2 K 4 K 8 K 16 K 24 K Block Size [Byte] Diff Image Size (21MB-25MB) Compressed Size (18MB to 12MB) 31

32 Influence of Block Size on Archive Size Size of repository/image [MByte] K 2 K 4 K 8 K 16 K 24 K Block Size [Byte] Compression ratio [% of original size] Diff Image Size (21MB-25MB) Compressed Size (18MB to 12MB) Compressed ratio (86% to 49%) 32

33 Conclusions Identified partitions as state of software installation. Changes along two axes. Designed partition repositories as efficient storage scheme (e.g. archive 75 localized Windows NT partitions in twice the size of one partition). Proposed cluster software maintenance system based on efficient storage scheme and optimized distribution. Our tools are file system independent and therefore work with all operating systems (even future versions of current systems). 33

34 Questions? CoPs - Project Cluster of PCs 34

35 Block Size: Initial Repository Size of repository/image [MByte] K 2 K 4 K 8 K 16 K 24 K Compression ratio [% of original size] Raw Image Size (200MB-192MB) Compressed Size (113MB to 66 MB) Compressed ratio (59% to 30%) Block Size [Byte] 35