Introduction to the tutorial environment

The tutorial-setup.sh script creates the following service model members and organizers to initialize the CRM service model in Service Impact.

  • The Dashboard organizer.

    This root-level organizer for service models as a whole, a best practice. Initially, the organizer is empty.

  • The root-level CRM - Development organizer, containing additional organizers.

    Zenoss recommends using a single root-level organizer to contain the subservices of each service model, and using standardized names (and contents) for sub-organizers.

  • The CRM - Application Service and CRM - Compute Service service model members, children of the CRM - Development organizer.

    These members summarize the application and compute services associated that are with the CRM application, and are easily located without having to open the organizers in which their constituent subservices are located. This is a best practice.

  • The members in the Network organizer that start with zfake represent the network connections between fake devices.

    Because these fake devices are not modeled, Resource Manager cannot discern their relationships, and Service Impact cannot create device or component members. Therefore, the setup script creates members to represent the connections.

    These members have neither contextual nor global policies, so the default policy applies: The state of the worst condition that affects child members becomes the state of the zfake members, which is the correct policy for these connections.

  • DNS and interface names follow a naming convention, a best practice.

  • The subservice members in the Network organizer that start with tx contain redundant resources, and standardized, global availability policies are defined.

    These subservice members embody several best practices:

    • Each subservice member contains homogeneous child members. Global policies work best when child members are homogeneous.
    • Each subservice uses global policies. Global policies can be re-used across service model boundaries. Contextual policies are restricted to specific service models.
    • Each global policy contains the following, standardized state triggers: The availability state is ATRISK if 50% or more child members are down, and DOWN if 100% of child members are down. By using percentage thresholds, the policies do not need adjustment if additional resources are deployed later.

The remaining procedures in this tutorial demonstrate how to complete and test the CRM service model.