IT Virtualization OpenStack scenario

The following example of an OpenStack environment provides insights into any environment consisting of, for example, a combination of physical services and storage combined with virtualization from VMware, or similar virtualization providing infrastructure.

IT virtualization

The following figure depicts a Hypervisor running a VM (LB Server) that is assigned to a tenant, has classification data and a number of network interfaces. Each network interface has a MAC address, one or more IP addresses (v4 or v6) and each IP address is considered to be part of an IP subnet. It is also related to orchestration data from Heat that helps identify how the instance was created.

Figure depicting an example multi-domain topology.
Figure. Example multi-domain topology

Property use guidance

Although the topology service is flexible, you should use the following guidelines when setting property values to ensure that elements are appropriately represented:

  • Set entityType to one of the pre-defined entity types with an associated icon where possible.
  • Set name and description to values that are easy to read or remember wherever possible.
  • Use the default generic properties to represent generally applicable characteristics of an element and to provide a basic degree of labeling and filtering. For a list of generic properties, see the following topic: Properties

Model patterns - Part one

Stepping through each of the sections of the example of a multi-domain topology helps to identify reusable patterns.

In the following figure, the Hypervisor 'TSLKVM04' is running a VM 'LB Server'.

Figure of Hypervisor
Figure. Figure of Hypervisor

The LB Server in this image is:

  • Assigned to the 'MWC' tenant
  • Contains three network interfaces
  • Uses the Haproxy _nProbe image (OpenStack image)
  • Is classified as an MWC2-c _balancer (OpenStack flavor)

This means that the following pattern can be identified:

Pattern
Figure. Pattern

Usage tips:

  • The associations shown for flavor, image and person are optional.

  • Network interfaces and other components of the device must be associated with it through a partOf relationship. The exception is if an IP or MAC address is known independently of any device, for example flow data would expose those but the device would be unknown.

  • The FQDN (hostname, short or full DNS name) is associated directly with the server in this case as nothing else is known about the Hypervisor.

    Note: This is not shown in the topology fragment.

  • The partOf composition is not shown by the topology GUI, but must be created where the relationship between a component and a device is known. This is in addition to relationships such as contains, which the IBM Cloud Pak for AIOps console will show.

Hypervisor example JSON

{
    "_executionTime": 3,
    "createTime": 1501741671066,
    "name": "TSLKVM04",
    "uniqueId": "CYooventry_DC1:MWC/ComputeHost/TSLKVM04",
    "observedTime": 1501776262368,
    "_startedAt": "2017-08-03T06:27:51.066Z",
    "entityTypes": [
        "server"
    ],
    "beginTime": 1501741671066,
    "_id": "KNN6TCGhKyM4MCI6jooGWg",
    "_observedAt": "2017-08-03T16:04:22.368Z",
    "_modifiedAt": "2017-08-03T06:27:51.066Z",
    "_createdAt": "2017-08-03T06:27:51.066Z",
    "changeTime": 1501741671066,
    "matchTokens": [
        "Coventry_DC1:MWC/ComputeHost/TSLKVM04",
        "TSLKVM04"
    ]
}

Note: Many of the properties starting with _ are internal (such as timestamps). Also:

  • The uniqueId is a composite of a number of fields: data center, tenant, className and name of the Hypervisor because the ID is a highly ambiguous integer.
  • The name is the name of the instance from OpenStack.
  • The entityType is set to 'server' to ensure correct classification and icon use.

Virtual machine example JSON

{
    "instanceName": "LB server",
    "tenantId": "2f79c691570c4a598be386325ea01da8",
    "launchedAt": 1501741751194,
    "_executionTime": 4,
    "userId": "48c7cd25ad0842be8e9b84390de0e587",
    "imageName": "None Available",
    "availabilityZone": "nova",
    "createTime": 1501741733817,
    "flavorName": "m1.nano",
    "name": "LB server",
    "uniqueId": "1e35c68a-86b0-445f-9741-e581121a0577",
    "serverStatus": "active",
    "observedTime": 1501741752717,
    "_startedAt": "2017-08-03T06:29:12.717Z",
    "entityTypes": [
        "server",
        "vm"
    ],
    "beginTime": 1501741752717,
    "flavorId": "42",
    "vmState": "active",
    "_id": "3nDmTkKfrvNhZinSDCYHDw",
    "_observedAt": "2017-08-03T06:29:12.717Z",
    "createdAt": 1501741733000,
    "_modifiedAt": "2017-08-03T06:29:12.717Z",
    "_createdAt": "2017-08-03T06:28:53.817Z",
    "changeTime": 1501741752717,
    "matchTokens": [
        "1e35c68a-86b0-445f-9741-e581121a0577",
        "LB server"
    ]
}

Note: Many of the properties starting with _ are internal (such as timestamps). Also:

  • The uniqueId in this case is the UUID of the instance from OpenStack.
  • The name is the name of the instance from OpenStack.
  • The entityType is set to 'server' and 'vm' to ensure correct classification and icon use.
  • The isVirtual Boolean is set to true.

Network interface example JSON

{
    "_executionTime": 3,
    "isAdminStateUp": true,
    "createTime": 1501741717674,
    "name": "aab47c85-3110-401a-8bad-960b7c4bcd7b",
    "uniqueId": "aab47c85-3110-401a-8bad-960b7c4bcd7b",
    "observedTime": 1501741718855,
    "_startedAt": "2017-08-03T06:28:38.855Z",
    "entityTypes": [
        "networkinterface"
    ],
    "beginTime": 1501741718855,
    "isPortSecurityEnabled": true,
    "_id": "kkKpDH6yLn7cmNVXOddImg",
    "_observedAt": "2017-08-03T06:28:38.855Z",
    "_modifiedAt": "2017-08-03T06:28:38.855Z",
    "_createdAt": "2017-08-03T06:28:37.674Z",
    "changeTime": 1501741718855,
    "matchTokens": [
        "aab47c85-3110-401a-8bad-960b7c4bcd7b"
    ]
}

Note: As with the LB Server data, many of the properties are internal. Also:

  • The uniqueId in this case is the UUID of the instance from OpenStack.
  • The name is the name of the instance from OpenStack.
  • The entityType is set to networkinterface to ensure correct classification and icon use.
  • The type of the interface (such as ifType from IBM Tivoli Network Manager) is unknown.

Model patterns - Part two

Note: Each section of the example of the multi-domain topology identifies the reusable patterns.

In the following figure, the LB Server VM contains a network interface.

Figure showing the LB Server VM
Figure. LB Server VM

The network interface in this image is:

  • Accessed through an IP address and a MAC address
  • Classified by a Heat orchestration resource

This means that the following pattern can be identified:

Pattern
Figure. Pattern

Usage Tips:

  • The Heat orchestration element and relationship is optional. Such things can be added if known to provide extra context.

  • The network interface must be contained by and partOf the device. Contains is more fine-grained and may reference intermediate cards (for example) within the containment hierarchy of the device, such as

    json device--contains-->card--->contains--->port

  • If an IP address, FQDN or MAC address is known to be related to a specific device, then they must be associated with the device through a partOf relationship in addition to the accessedVia relationship.

  • If an IP address, FQDN, or MAC address is known independently of a device, then no partOf relationship from them is necessary.

  • If an IP address is known to resolve to an FQDN, then relationships between them should be created to depict that one resolves to another and one accesses another (accessedVia shown in the example).

IP address example JSON

{
    "_executionTime": 3,
    "createTime": 1501741717656,
    "name": "172.24.4.5",
    "uniqueId": "172.24.4.5",
    "ipNumber": 2887255045,
    "addressSpace": "Coventry_DC1:MWC",
    "observedTime": 1501741731565,
    "_startedAt": "2017-08-03T06:28:51.565Z",
    "entityTypes": [
        "ipaddress"
    ],
    "beginTime": 1501741731565,
    "version": "IPv4",
    "_id": "jPLc72DU-UvPeTQE_7YdPQ",
    "_observedAt": "2017-08-03T06:28:51.565Z",
    "_modifiedAt": "2017-08-03T06:28:51.565Z",
    "_createdAt": "2017-08-03T06:28:37.656Z",
    "changeTime": 1501741731565,
    "matchTokens": [
        "172.24.4.5",
        "IPv4:2887255045"
    ]
}

Note:

  • The uniqueId is the IP address itself. This is an RFC1918 IP address and so it must be qualified with an address space to disambiguate it from other instances of the same IP address. Similar precautions should be used with MAC addresses, which can be ambiguous.
  • The protocol reflects whether the IP address is an IPv4 or IPv6 address.
  • The ipNumber is a numeric representation of the IPv4 or IPv6 address. A Java BigInteger has the precision to represent IPv6 addresses.

Model patterns - Part three

Figure showing multi-domain topology
Figure. Multi-domain topology

This means that the following pattern can be identified:

Pattern
Figure. Pattern

Usage Tips:

  • The IP subnet should aggregate any IP addresses known to be in it.

  • Elements accessed through an IP should be related to it, such as a network interface, service, or process.

  • If an FQDN is known to resolve to an IP address (and vice-versa), then they should be related.

  • If a MAC address is known to bind to an IP address and vice-versa, they should be related.

  • If an IP address, MAC address, or FQDN is known to relate to a device, they should be considered partOf it; otherwise, they are independent.

IP subnet example JSON

{
  "uniqueId": "c009ff59-13b9-48dc-8863-cd0c75070d99",
  "name": "172.24.4.0/24 (public-subnet)",
  "entityTypes": [
    "subnet"
  ],
  "matchTokens": [
    "172.24.4.0/24 (public-subnet)",
    "172.24.4.0/24",
    "c009ff59-13b9-48dc-8863-cd0c75070d99"
  ],
  "_id": "u0sjaHcumtg5A4DRl1fyAQ",
  "_references": [
    {
      "_id": "9duzx1-3o52g-ys5-47si0",
      "_edgeType": "contains",
      "_label": "aggregation",
      "_fromId": "u0sjaHcumtg5A4DRl1fyAQ",
      "_toId": "lSJQs8JmYzDQ-_wUOfvJbg",
      "_fromUniqueId": "c009ff59-13b9-48dc-8863-cd0c75070d99",
      "_toUniqueId": "172.24.4.12",
      "createTime": 1501838680418,
      "_observedAt": "2017-08-04T09:24:40.418Z",
      "_createdAt": "2017-08-04T09:24:40.418Z",
      "beginTime": 1501838680418,
      "_startedAt": "2017-08-04T09:24:40.418Z",
      "observedTime": 1501838680418
    },
  ],
  "_executionTime": 11,
  "_modifiedAt": "2017-08-04T09:24:40.356Z",
  "isDhcpEnabled": false,
  "dnsNames": "None Available",
  "_observedAt": "2017-08-04T09:24:40.356Z",
  "gatewayIp": "172.24.4.1",
  "_startedAt": "2017-08-04T09:24:40.356Z",
  "observedTime": 1501838680356,
  "changeTime": 1501838680356,
  "ipVersion": "V4",
  "createTime": 1501838680356,
  "_createdAt": "2017-08-04T09:24:40.356Z",
  "cidr": "172.24.4.0/24",
  "networkId": "3e2b5d07-653a-4fc8-8224-45801d9d113f",
  "beginTime": 1501838680356,
  "allocationPools": "172.24.4.2-to-172.24.4.254"
}

Notes:

  • The uniqueId in this case is the UUID of the subnet from OpenStack.
  • The name in this case is set to CIDR notation plus the ID of the subnet.
  • The entityType is set to subnet to ensure appropriate classification and icon usage.
  • Some example relationships are shown: For example, an IP address that is part of the subnet is visible, and the subnet's use of an allocation pool is also depicted.