Fleecing Design Considerations and Requirements


#1

A number of questions have come up concerning ManageIQ’s fleecing feature and why we chose the current design/implementation as opposed to an alternative. The current fleecing implementation was initially released in 2007. From then, we have been aware of alternative solutions, but they were rejected for very specific reasons. The requirements and design considerations listed below are based on years of market research and interaction with large enterprise customers.

  1. Flexible virtual disk access
    Given the variation between the types of environments we support, and the restrictions imposed within instances of said environments, we cannot assume filesystem-level access to virtual disks (neither local nor remote).
    This layer of abstraction enables us to optimize virtual disk access for given environments and installations as needed, and should enable us to easily address new environments in the future.
    • For example, in many instances the only access management software is granted to a virtual infrastructure environment is through a well defined management API. In cases like this, we are able to access the virtual disks of VMs through the API, and fleece them accordingly.
    • Through our experience with large enterprise customers, we’ve concluded that this is the preferred access method, when available. It affords us the greatest amount of flexibility in appliance placement, and enables access to restricted environments, which would otherwise be inaccessible.
  2. Lightweight
    Each fleece task needs to be able to run in a single thread of a worker process. This enables us to parallelize the fleecing workload M x N (threads by workers).
    Each fleecing task must also consume minimal system resources (memory, CPU, etc.) as to not adversely impact the operation of the appliance as a whole.
  3. Minimal Dependencies
    Our current implementation requires only Ruby and requisite provider libraries. This affords a number of benefits:
    • It does not encumber appliance configuration with additional dependencies.
    • Enables the creation of self-contained proxy executables.
    • Facilitates the deployment of proxies to foreign environments.
  4. OS and Environment Agnostic
    • Our current implementation is written almost entirely in pure Ruby.
    • Will run in most environments that support Ruby.
    • Can run in Windows and Linux environments.
    • Facilitates the development of proxies for deployment to foreign environments.
  5. Fine-grained Control of the I/O Path
    Our fleecing stack gives us full control of the I/O path, independent of the kernel’s native I/O implementation. This enables us to employ portions of the fleecing stack to address issues that could not be addressed otherwise.
    • For example, we can access shared resources (LUNs for example) even when said resources are not intended to be shared. Normally, the multiple layers of caching in the kernel’s native I/O stack would make this impossible. Our fleecing stack gives us full control over every layer of caching, allowing us to easily address the sharing problem.
    • In addition, our fleecing stack has been reconfigured, rewired and re-purposed in many ways to address problems, and support environments, which would have been otherwise impossible.