Uploaded image for project: 'OpenStack Strategy'
  1. OpenStack Strategy
  2. RHOSSTRAT-1195

Tiering mechanism framework

XMLWordPrintable

    • Icon: Initiative Initiative
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • None
    • Not Selected
    • False
    • False
    • Hide

      None

      Show
      None
    • 0
    • 0

      Initiative Overview

      This initiative will bring design and skeleton project for a tiering tool for RHOSO. Tiering has to be possible in three major resource areas which are compute area, storage area and network area. By tiering it is meant to limit resources of the specific areas and in the same time to ensure resource allocation for VM instances based on defined tiers (or performance profiles) and assigning those to the VM instances. We need to design suitable project/tool and prepare it for implementation of underlying resource areas logic by subject matter experts.{}

      The idea here would be to create an operator (distinct from installer operators) that would hold the above definition and be responsible for configuring the various services to provide the performance tiers. The scoping would be around a node set, such that you apply a set of resource limits to a given set of nodes that all have the same physical limitations (i.e. the same network links, the same disk performance, and the same CPU arrangement). Grouping constructs such as host aggregates could be maintained by this operator according to the hosts in the node set to allow for targeted booting.

      The definition of the profiles generally in terms of the resources they constrain and how they’re constrained is also part of this initiative. Then we apply some subset of those to a given scope of compute nodes (via aggregate) and also define the characteristics of those hosts for when we need to calculate percentages of the total host. The “relative_prio” number on each is just an arbitrary sorting key so if something like Watcher needs to take action, it could know “better to disrupt a silver with a migration than a platinum, because the platinum is more important”. This could also be inferred by the ordering in the “tiers:” key in the scopes, allowing for different relative importance meanings in different scopes.

      Detailed draft of profile definition can be found in Tiering Proposal.

      Goals

      • Create higher level operator for tiering purposes
      • Define performance profiles and have it verified by SMEs
      • Design and prepare relevant CRDs

      Requirements:

      Requirement Notes isMVP?
      Shell operator for the per service controller implementation   yes
      CRD definition   yes
      Performance profiles per resource area   yes

       

      Done - Acceptance Criteria:

      • shell operator is created and it is possible to proceed with implementation of controllers for each resource area
      • all relevant performance profiles are defined
      • CRDs for each resource area are defined and validated by implementers of resource area controllers

      Out of Scope:

      • Implementation of resource allocation enforcement

              mmagr@redhat.com Martin Magr
              mmagr@redhat.com Martin Magr
              Edu Alcaniz Edu Alcaniz
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: