Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Service list

This table describes the services that your system runs. Each service runs within its own Docker container. For each service, the table lists:

  • RAM needed per instance: The amount of RAM that, by default, the service needs on each instance on which it's deployed. For all services except for System services, this value is also the default Docker Container Memory value for the service.
  • Number of instances: Shows both:
    • The required number of instances on which a service must run for the system to function properly.
    • The recommended number of instances that you should run a service on. These are recommended minimums; if your system includes more instances, you should take advantage of them by running services on them.
  • Service unit cost per instance: The number of service units that it costs to run the service on one instance. This cost indicates how computationally expensive one service is compared to another.
  • Whether the service is persistent (that is, it must run on a specific instance) or supports floating (that is, it can run on any instance).
  • Whether the service has a single type or multiple.
Note For services with both the Container Memory and Max Heap Size settings, the Container Memory setting should be larger than the Max Heap Size setting.

Service name and description

Service properties

The services perform functions related to the system's supported use cases. You can move, scale, and reconfigure these services.

Admin-App

Runs the Admin App.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

10

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Cluster-Coordination

Mesos (master) - https://mesos.apache.org

Hardware resource management solution for distributed systems.

How it's used

Manages hardware resource allocation.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

1

Persistent or floating

Persistent

Supports volume configuration

No

Single or multiple types

Single

Cluster-Worker

Mesos (slave) - https://mesos.apache.org

Hardware resource management solution for distributed systems.

How it's used

Receives and performs work from other services.

Note: Though the Cluster-Worker service has a low service unit cost, it can at times appear to be using a large amount of CPU resources. When other services use Cluster-Worker to perform their work, Cluster-Worker reflects the CPU usage of those services.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

5

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Clustered-File-System

https://hortonworks.com/apache/hdfs

Hadoop Distributed File System. A distributed file system used for storing data.

Important: The Clustered-File-System service is offered as a technology preview. Do not use it on a production system

RAM needed per instance

Data Node: 751 MB

Name Node: 1024 MB

Journal Node: 256 MB

Number of instances

See Clustered-File-System service considerations

Service unit cost per instance

Data Node: 5

Name Node: 10

Journal Node: 1

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Multiple:

  • Data Node: Stores data
  • Name Node: Tracks the data stored in Data Nodes
  • Journal Node: Tracks changes made by the Name Nodes

Dashboard

https://www.elastic.co/products/kibana

Visualizes information stored in Elasticsearch indexes.

How it's used

Powers the advanced Dashboard Management service.

Note: This service is in the Unconfigured state by default.

RAM needed per instance

300 MB

Number of instances

Required: 0

Optimal: 2

Service unit cost per instance

5

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Database

http://cassandra.apache.org/

Decentralized database that can be scaled across large numbers of hardware nodes.

How it's used

Stores system configuration data. Also stores document discovery and failure data for workflow tasks.

RAM needed per instance

2.4 GB

Number of instances

Required: 1

Optimal: 3

Service unit cost per instance

10

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Index

http://lucene.apache.org/solr/

Data indexing and search platform.

How it's used

The search engine that manages all internal search indexes.

RAM needed per instance

2 GB

Number of instances

Required: 0

Optimal: 3

Notes:

  • No instances are required to run this service, but without at least one, you cannot index data.
  • If multiple copies of an index exist (with an Index Protection Level greater than one), each copy is managed by a separate instance of the Index service.

Service unit cost per instance

25

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Logging

https://www.elastic.co/products/logstash

Collection engine for event data. Can perform transformations on the data it collects and then send that data to a number of outputs.

How it's used

Transports system logs and metrics data to the Metrics service.

RAM needed per instance

700 MB

Number of instances

Required: 1

Optimal: 1

Service unit cost per instance

10

Persistent or floating

Floating

Supports volume configuration

Yes

Single or multiple types

Single

Message Queue

https://kafka.apache.org/

Stream processing platform for handling real-time data streams.

How it's used

Facilitates communication between instances.

RAM needed per instance

2 GB

Number of instances

Required: 1

Optimal: 3

Service unit cost per instance

5

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Metrics

https://www.elastic.co/

Data indexing and search platform.

How it's used

Stores and manages:

  • System events

  • Workflow performance data

  • Workflow failure data

The service maintains this information in a number of internally-managed Metrics indexes.

RAM needed per instance

2000 MB

Number of instances

Required: 1

Optimal: 3

Service unit cost per instance

25

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Monitor-App

Powers the Monitor App.

RAM needed per instance

556 MB

Number of instances

Required: 0

Optimal: 1

Note: Scaling the Monitor-App service does not affect any of the workflows that collect data from the systems you are monitoring. For example, if you scale the service to run on 0 instances, users cannot access the Monitor App, but HCI will continue to collect data.

Service unit cost per instance

10

Persistent or floating

Floating

Supports volume configuration

Yes

Single or multiple types

Single

Network-Proxy

HAProxy - https://haproxy.org

Load balancer for TCP and HTTP-based applications.

How it's used

Maps network requests to the instances where the applicable services are located.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

1

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Scheduling

https://mesos.github.io/chronos/

Job scheduler for Apache Mesos.

How it's used

Schedules workflow tasks.

RAM needed per instance

712 MB

Number of instances

Required: 1

Optimal: 1

Service unit cost per instance

1

Persistent or floating

Floating

Supports volume configuration

Yes

Single or multiple types

Single

Search-App

Powers the Search App

RAM needed per instance

556 MB

Number of instances

Required: 0

Optimal: 2

Note: No instances are required to run this service, but without at least one, the Search App is unavailable.

Service unit cost per instance

10

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Sentinel

Runs internal system processes and monitors the health of the other services.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

5

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Service-Deployment

Marathon - https://mesosphere.github.io/marathon/

Orchestration platform for Mesos applications.

How it's used

Handles deployment of high-level services (that is, the services that you can configure).

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

1

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Synchronization

Apache Zookeeper - https://zookeeper.apache.org/

Coordinates configuration settings and other information between a number of distributed services.

How it's used

Coordinates actions and database operations across instances.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

5

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Watchdog

Monitors the other System Services and restarts them if necessary. Also responsible for initial system startup.

RAM needed per instance

N/A

Number of instances

N/A

Service unit cost per instance

5

Persistent or floating

Persistent

Supports volume configuration

Yes

Single or multiple types

Single

Clustered-File-System service considerations

The Clustered-File-System service gives storage space to other services in an HCI system.

ImportantThe Clustered-File-System service is offered as a technology preview. Do not use it on a production system.
Multiple service instance types

Each instance of the Clustered-File-System service can be one of these types:

  • Data Node: Stores data
  • Name Node: Tracks the data stored in Data Nodes
  • Journal Node: Tracks changes made by the Name Nodes

You can run multiple different Clustered-File-System service instance types on an HCI instance. For example, a single HCI instance can run both a Journal Node and a Data Node instances of the Clustered-File-System service.

You cannot run multiple Clustered-File-System service instances of the same type on an HCI instance. For example, a single HCI instance cannot run two Data Node instances.

Deployment modes

The Clustered-File-System service can be deployed in either of these modes:

  • High Availability (HA) Mode: In HA mode, the Clustered-File-System service can retain its stored data in the event that a Name Node instance fails or becomes corrupt.
  • Non-HA Mode: In Non-HA mode, the Clustered-File-System service has a single Name Node instance. If this instance fails or becomes corrupt, all data stored by the Clustered-File-System service is lost.

The service's deployment mode is determined based on the number of service type instances you have when you initially deploy the service. After the deployment mode is set, you cannot change it without losing all data stored by the Clustered-File-System service.

Initial deployment requirements: HA mode

To deploy the Clustered-File-System service in HA mode, you need at least three HCI instances.

Upon initial deployment of the service, you need to configure the service to run:

  • Exactly two Name Node instances
  • Exactly three Journal Node instances

You can run any number of Data Node instances. You need at least one to be able to store data. For HA mode, the recommended minimum is three.

Initial deployment requirements: Non-HA mode

To deploy the Clustered-File-System service in Non-HA mode, you need only one HCI instance.

Upon initial deployment of the service, you need to configure the service to run:

  • Exactly one Name Node instance
  • Zero Journal Node instances

You can run any number of Data Node instances. You need at least one to be able to store data.

Scaling and moving the service
CautionScaling Clustered-File-System such that you have zero Name Node instances causes the Clustered-File-System service to lose track of all data stored on its Data Node instances.

When scaling or moving Name Node or Journal Node service instances, you need to perform only one operation at time.

For example, to move a Name Node from one HCI instance to another, you need to:

  1. Run a service operation to remove an instance of the Name Node service type.
  2. Wait for the operation to finish.
  3. Run a service operation to start a new instance of the Name Node service type.
  4. Wait for the operation to finish.

When running the Clustered-File-System service in HA mode, you need at least two Journal Node instances running. Scaling the service such that you have zero or one Journal Node instances causes the service to become unresponsive.

You can scale or move as many Data Node instances as necessary.

Changing deployment modes

When you initially deploy the Clustered-File-System service, it is deployed in either HA or Non-HA mode, depending on the number of service instances types you initially configure the service to run.

You can change the Clustered-File-System deployment mode after the service is initially deployed, however this needs a complete redeployment of the service.

CautionChanging deployment modes causes the Clustered-File-System service to lose track of all data stored on its Data Node instances. Because of this, you should remove all existing Data Node instances and create new ones when changing the Clustered-File-System deployment mode.

To switch from one deployment mode to another:

  1. Scale Clustered-File-System to run on zero instances in the system.
  2. Configure and run a service scale task to scale Clustered-File-System to the applicable number of service type instances.
    ImportantName Node and Journal Node types must be scaled together in a single operation.

 

  • Was this article helpful?