| Home | Trees | Indices | Help |
|---|
|
|
The Haizea VM Scheduler
This class is responsible for taking a lease and scheduling VMs to satisfy the requirements of that lease.
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
Inherited from |
|||
|
|||
|
Inherited from |
|||
|
|||
Constructor The constructor does little more than create the VM scheduler's attributes. However, it does expect (in the arguments) a fully-constructed SlotTable, ResourcePool, and Mapper (these are constructed in the Manager's constructor). Arguments: slottable -- Slot table resourcepool -- Resource pool where enactment commands will be sent to mapper -- Mapper
|
The scheduling function This particular function doesn't do much except call __schedule_asap and __schedule_exact (which do all the work). Arguments: lease -- Lease to schedule nexttime -- The next time at which the scheduler can allocate resources. earliest -- The earliest possible starting times on each physical node |
Estimates the time required to migrate a lease's VMs This function conservatively estimates that all the VMs are going to be migrated to other nodes. Since all the transfers are intra-node, the bottleneck is the transfer from whatever node has the most memory to transfer. Note that this method only estimates the time to migrate the memory state files for the VMs. Migrating the software environment (which may or may not be a disk image) is the responsibility of the preparation scheduler, which has it's own set of migration scheduling methods. Arguments: lease -- Lease that might be migrated |
Schedules migrations for a lease Arguments: lease -- Lease being migrated vmrr -- The VM reservation before which the migration will take place nexttime -- The next time at which the scheduler can allocate resources. |
Cancels a VM resource reservation Arguments: vmrr -- VM RR to be cancelled |
Determines if it is possible to suspend a lease before a given time Arguments: vmrr -- VM RR to be preempted t -- Time by which the VM must be preempted |
Preempts a VM reservation at a given time This method assumes that the lease is, in fact, preemptable, that the VMs are running at the given time, and that there is enough time to suspend the VMs before the given time (all these checks are done in the lease scheduler). Arguments: vmrr -- VM RR to be preempted t -- Time by which the VM must be preempted |
Returns a list of future leases that are reschedulable. Currently, this list is just the best-effort leases scheduled in the future as determined by the backfilling algorithm. Advance reservation leases, by their nature, cannot be rescheduled to find a "better" starting time. |
Computes resource utilization (currently just CPU-based) This utilization information shows what portion of the physical resources is used by each type of reservation (e.g., 70% are running a VM, 5% are doing suspensions, etc.) Arguments: time -- Time at which to determine utilization |
Schedules VMs that must start at an exact time This type of lease is "easy" to schedule because we know the exact start time, which means that's the only starting time we have to check. So, this method does little more than call the mapper. Arguments: lease -- Lease to schedule nexttime -- The next time at which the scheduler can allocate resources. earliest -- The earliest possible starting times on each physical node |
Schedules VMs as soon as possible This method is a bit more complex that __schedule_exact because we need to figure out what "as soon as possible" actually is. This involves attempting several mappings, at different points in time, before we can schedule the lease. This method will always check, at least, if the lease can be scheduled at the earliest possible moment at which the lease could be prepared (e.g., if the lease can't start until 1 hour in the future because that's the earliest possible time at which the disk images it requires can be transferred, then that's when the scheduler will check). Note, however, that this "earliest possible moment" is determined by the preparation scheduler. Additionally, if the lease can't be scheduled at the earliest possible moment, it can also check if the lease can be scheduled in the future. This partially implements a backfilling algorithm (the maximum number of future leases is stored in the max_in_future attribute of VMScheduler), the other part being implemented in the __process_queue method of LeaseScheduler. Note that, if the method is allowed to scheduled in the future, and assuming that the lease doesn't request more resources than the site itself, this method will always schedule the VMs succesfully (since there's always an empty spot somewhere in the future). Arguments: lease -- Lease to schedule nexttime -- The next time at which the scheduler can allocate resources. earliest -- The earliest possible starting times on each physical node allow_in_future -- Boolean indicating whether the scheduler is allowed to schedule the VMs in the future. |
Tries to map a lease in a given list of points in time This method goes through a given list of points in time and tries to find the earliest time at which that lease can be allocated resources. Arguments: lease -- Lease to schedule requested_resources -- A dictionary of lease node -> ResourceTuple. changepoints -- The list of changepoints duration -- The amount of time requested min_duration -- The minimum amount of time that should be allocated Returns: start -- The time at which resources have been found for the lease actualend -- The time at which the resources won't be available. Note that this is not necessarily (start + duration) since the mapper might be unable to find enough resources for the full requested duration. mapping -- A mapping of lease nodes to physical nodes preemptions -- A list of (if no mapping is found, all these values are set to None) |
Computes the times at which suspend/resume operations would have to start When suspending or resuming a VM, the VM's memory is dumped to a file on disk. To correctly estimate the time required to suspend a lease with multiple VMs, Haizea makes sure that no two suspensions/resumptions happen at the same time (e.g., if eight memory files were being saved at the same time to disk, the disk's performance would be reduced in a way that is not as easy to estimate as if only one file were being saved at a time). Based on a number of parameters, this method estimates the times at which the suspend/resume commands would have to be sent to guarantee this exclusion. Arguments: vmrr -- The VM reservation that will be suspended/resumed time -- The time at which the suspend should end or the resume should start. direction -- DIRECTION_BACKWARD: start at "time" and compute the times going backward (for suspensions) DIRECTION_FORWARD: start at time "time" and compute the times going forward. exclusion -- SUSPRES_EXCLUSION_GLOBAL (memory is saved to global filesystem) or SUSPRES_EXCLUSION_LOCAL (saved to local filesystem) rate -- The rate at which an individual VM is suspended/resumed override -- If specified, then instead of computing the time to suspend/resume VM based on its memory and the "rate" parameter, use this override value. |
Schedules the shutdown of a VM reservation Arguments: vmrr -- The VM reservation that will be shutdown |
Schedules the suspension of a VM reservation Most of the work is done in __compute_susprem_times. See that method's documentation for more details. Arguments: vmrr -- The VM reservation that will be suspended suspend_by -- The time by which the VMs should be suspended. |
Schedules the resumption of a VM reservation Most of the work is done in __compute_susprem_times. See that method's documentation for more details. Arguments: vmrr -- The VM reservation that will be resumed resume_at -- The time at which the resumption should start |
Compute the time to suspend/resume a single VM Arguments: mem -- Amount of memory used by the VM rate -- The rate at which an individual VM is suspended/resumed |
Estimate the time to suspend an entire lease Most of the work is done in __estimate_suspend_resume_time. See that method's documentation for more details. Arguments: lease -- Lease that is going to be suspended |
Estimate the time to resume an entire lease Most of the work is done in __estimate_suspend_resume_time. See that method's documentation for more details. Arguments: lease -- Lease that is going to be resumed |
Estimate the time to suspend/resume an entire lease Note that, unlike __compute_suspend_resume_time, this estimates the time to suspend/resume an entire lease (which may involve suspending several VMs) Arguments: lease -- Lease that is going to be suspended/resumed rate -- The rate at which an individual VM is suspended/resumed |
Estimate the time to shutdown an entire lease Arguments: lease -- Lease that is going to be shutdown |
Compute the scheduling threshold (the 'minimum duration') of a lease To avoid thrashing, Haizea will not schedule a lease unless all overheads can be correctly scheduled (which includes image transfers, suspensions, etc.). However, this can still result in situations where a lease is prepared, and then immediately suspended because of a blocking lease in the future. The scheduling threshold is used to specify that a lease must not be scheduled unless it is guaranteed to run for a minimum amount of time (the rationale behind this is that you ideally don't want leases to be scheduled if they're not going to be active for at least as much time as was spent in overheads). An important part of computing this value is the "scheduling threshold factor". The default value is 1, meaning that the lease will be active for at least as much time T as was spent on overheads (e.g., if preparing the lease requires 60 seconds, and we know that it will have to be suspended, requiring 30 seconds, Haizea won't schedule the lease unless it can run for at least 90 minutes). In other words, a scheduling factor of F required a minimum duration of F*T. A value of 0 could lead to thrashing, since Haizea could end up with situations where a lease starts and immediately gets suspended. Arguments: lease -- Lease for which we want to find the scheduling threshold |
Handles the start of a VMResourceReservation Arguments: l -- Lease the VMResourceReservation belongs to rr -- THe VMResourceReservation |
Handles the end of a VMResourceReservation Arguments: l -- Lease the VMResourceReservation belongs to rr -- THe VMResourceReservation |
Handles the unexpected end of a VMResourceReservation Arguments: l -- Lease the VMResourceReservation belongs to rr -- THe VMResourceReservation |
Handles the start of a SuspensionResourceReservation Arguments: l -- Lease the SuspensionResourceReservation belongs to rr -- The SuspensionResourceReservation |
Handles the end of a SuspensionResourceReservation Arguments: l -- Lease the SuspensionResourceReservation belongs to rr -- The SuspensionResourceReservation |
Handles the start of a ResumptionResourceReservation Arguments: l -- Lease the ResumptionResourceReservation belongs to rr -- The ResumptionResourceReservation |
Handles the end of a ResumptionResourceReservation Arguments: l -- Lease the ResumptionResourceReservation belongs to rr -- The ResumptionResourceReservation |
Handles the start of a ShutdownResourceReservation Arguments: l -- Lease the SuspensionResourceReservation belongs to rr -- The SuspensionResourceReservation |
Handles the end of a SuspensionResourceReservation Arguments: l -- Lease the SuspensionResourceReservation belongs to rr -- The SuspensionResourceReservation |
Handles the start of a MemImageMigrationResourceReservation Arguments: l -- Lease the MemImageMigrationResourceReservation belongs to rr -- The MemImageMigrationResourceReservation |
Handles the end of a MemImageMigrationResourceReservation Arguments: l -- Lease the MemImageMigrationResourceReservation belongs to rr -- The MemImageMigrationResourceReservation |
| Home | Trees | Indices | Help |
|---|
| Generated by Epydoc 3.0.1 on Thu Dec 17 10:59:22 2009 | http://epydoc.sourceforge.net |