Skip to content

Commit 0d9f2f1

Browse files
aucahuasiaucahuasi
committed
document cluster deployment mode for k8s and improve telemetry docs
1 parent 12ffafb commit 0d9f2f1

File tree

6 files changed

+126
-52
lines changed

6 files changed

+126
-52
lines changed

‎docs/admin.rst‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,8 +12,8 @@
1212
planning/index
1313
install/cloud/index
1414
install/on-prem/index
15+
install/cluster/index
1516
install/testing-an-install
16-
install/cluster
1717
app-config/index
1818
debugging/index
1919
security/index

docs/install/cluster.md renamed to docs/install/cluster/docker-compose-mode.md

Lines changed: 1 addition & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,6 @@
11
# Multinode Deployment with Docker Compose
22

3-
**Note**: *This deployment configuration is currently **experimental** and subject to future updates.*
4-
5-
This document provides step-by-step instructions for deploying **Graphistry** in a multinode environment using Docker Compose. In this architecture, both the **Leader** and **Follower** nodes can ingest datasets and files, with all nodes accessing the same **PostgreSQL** instance on the **Leader** node. As a result, **Follower** nodes can also perform data uploads, ensuring that both **Leader** and **Follower** nodes have equal access to dataset ingestion and visualization.
6-
7-
The leader and followers will share datasets using a **Distributed File System**, for example, using the **Network File System (NFS)** protocol. This setup allows all nodes to access the same dataset directory. This configuration ensures that **Graphistry** can be deployed across multiple machines, each with different **GPU** configuration profiles (some with more powerful GPUs, enabling **multi-GPU** on multinode setups), while keeping the dataset storage centralized and synchronized.
8-
9-
This deployment mode is flexible and can be used both in **on-premises** clusters or in the **cloud**. For example, it should be possible to use **Amazon Machine Images (AMIs)** from the [Graphistry AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-ppbjy2nny7xzk?sr=0-1&ref_=beagle&applicationId=AWSMPContessa), assigning Amazon VMs created from those images to the **leader** and **follower** roles. This allows for scalable and customizable cloud-based deployments with the same multinode architecture.
10-
11-
## Cluster Configuration Overview
12-
13-
1. **Leader Node**: Handles the ingestion of datasets, PostgreSQL write operations, and exposes the required PostgreSQL ports.
14-
2. **Follower Nodes**: Connect to the PostgreSQL instance on the leader and can visualize graphs using the shared datasets. However, they do not have their own attached PostgreSQL instance.
15-
3. **Shared Dataset**: All nodes will access the dataset directory using a **Distributed File System**. This ensures that the leader and followers use the same dataset, maintaining consistency across all nodes.
16-
4. **PostgreSQL**: The PostgreSQL instance on the **Leader** node is used by all nodes for querying. The **Nexus** service on the **Leader** manages access to the database, while **Follower** nodes also use the **Leader’s** PostgreSQL instance. Both **Leader** and **Follower** nodes can perform actions like user sign-ups and settings modifications through their own **Nexus** dashboards, with changes applied system-wide for consistency across all nodes.
3+
This document provides step-by-step instructions for deploying **Graphistry** in a multinode environment using Docker Compose.
174

185
## Configuration File: `cluster.env`
196

‎docs/install/cluster/index.rst‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
Cluster Installation
2+
========================
3+
4+
.. toctree::
5+
:maxdepth: 1
6+
7+
docker-compose-mode
8+
kubernetes-mode
9+
10+
11+
Multinode Deployment Overview
12+
------------------------
13+
14+
**Note**: *This deployment configuration is currently **experimental** and subject to future updates.*
15+
16+
17+
In this installation, both the **Leader** and **Follower** nodes can ingest datasets and files, with all nodes accessing the same **PostgreSQL** instance on the **Leader** node. As a result, **Follower** nodes can also perform data uploads, ensuring that both **Leader** and **Follower** nodes have equal access to dataset ingestion and visualization.
18+
19+
The leader and followers will share datasets using a **Distributed File System**, for example, using the **Network File System (NFS)** protocol. This setup allows all nodes to access the same dataset directory. This configuration ensures that **Graphistry** can be deployed across multiple machines, each with different **GPU** configuration profiles (some with more powerful GPUs, enabling **multi-GPU** on multinode setups), while keeping the dataset storage centralized and synchronized.
20+
21+
Cluster Configuration Overview
22+
^^^^^^^^^^^^^^^^^^^^^^^^
23+
24+
1. **Leader Node**:
25+
Handles the ingestion of datasets, PostgreSQL write operations, and exposes the required PostgreSQL ports.
26+
27+
2. **Follower Nodes**:
28+
Connect to the PostgreSQL instance on the leader and can visualize graphs using the shared datasets. However, they do not have their own attached PostgreSQL instance.
29+
30+
3. **Shared Data**:
31+
All nodes will access the same **datasets directory** using a **Distributed File System**. This ensures that the leader and followers use the same dataset, maintaining consistency across all nodes.
32+
33+
4. **PostgreSQL**:
34+
The PostgreSQL instance on the **Leader** node is used by all nodes for querying. The **Nexus** service on the **Leader** manages access to the database, while **Follower** nodes also use the **Leader’s** PostgreSQL instance. Both **Leader** and **Follower** nodes can perform actions like user sign-ups and settings modifications through their own **Nexus** dashboards, with changes applied system-wide for consistency across all nodes.
35+
36+
5. **Redis**:
37+
The Redis instance on the **Leader** will be used by all **Nexus** and **forge-etl-python** services on the **Follower** nodes. However, for **StreamGL** visualizations, each **Graphistry** instance will have its own Redis instance.

‎docs/install/cluster/kubernetes-mode.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# Multinode Deployment with Kubernetes
2+
3+
We can deploy a **Graphistry** cluster on any **Kubernetes (K8s)** distribution, making it versatile and adaptable to a variety of environments. Whether you're using a cloud-based solution like **Google Kubernetes Engine (GKE)**, **Amazon Elastic Kubernetes Service (EKS)**, or **Azure Kubernetes Service (AKS)**, or a local setup like **K3s** or **MicroK8s**, Graphistry can be deployed across any K8s platform.
4+
5+
As an example, you can follow the steps for deploying Graphistry on **K3s** or **Google Kubernetes Engine (GKE)** by referring to the [Graphistry Cluster setup guide](https://github.com/graphistry/graphistry-helm/tree/main/charts/values-overrides/examples/cluster). These steps are also a great reference for configuring your cluster on other Kubernetes distributions, including the setup of a **Distributed File System** for shared directories, such as using a **Network File System (NFS)** as an example.

‎docs/telemetry/index.rst‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,3 +6,42 @@ Telemetry
66

77
docker-compose
88
kubernetes
9+
10+
11+
Deploying Telemetry Services for Graphistry
12+
------------------------
13+
14+
Graphistry leverages **OpenTelemetry** to collect and export telemetry data, such as **metrics** and **traces**, from its services. Regardless of whether you are using the **Docker Compose** platform or the **Kubernetes** platform, the telemetry stack can be deployed in **three key modes**, offering flexibility in how data is collected and routed to observability tools. **Graphistry's telemetry stack** provides flexible deployment options for collecting and visualizing metrics and traces.
15+
16+
Both **Docker Compose and Kubernetes platforms** share **common specifications** for deploying OpenTelemetry, ensuring seamless integration and consistent behavior across environments. Whether you choose to forward telemetry data to external services, use packaged observability tools, or combine both methods in hybrid mode, the platforms offer a unified and scalable approach to telemetry data collection and export.
17+
18+
Common Deployment Modes
19+
^^^^^^^^^^^^^^^^^^^^^^^^
20+
21+
1. **Forwarding to External Services**
22+
23+
* Telemetry data is forwarded to external observability services (e.g., **Grafana Cloud**, **Datadog**, etc.).
24+
* Both platforms support configuration for sending telemetry data to **OTLP-compatible** endpoints.
25+
26+
2. **Using Packaged Observability Tools**
27+
28+
* A local stack of observability tools (e.g., **Prometheus**, **Grafana**, **Jaeger**, **NVIDIA/dcgm-exporter**, etc.) is deployed to collect and visualize telemetry data, including GPU metrics.
29+
* Both platforms offer the option to deploy this self-contained stack for on-premises monitoring.
30+
31+
3. **Hybrid Mode**
32+
33+
* Can combine both local observability tools and external services for telemetry data routing.
34+
* Data can be sent both to internal tools (e.g., **Prometheus**) and external observability platforms for comprehensive monitoring.
35+
* Provides more flexibility for custom deployments, such as **skipping forwarding to the OpenTelemetry Collector** and **forwarding to a custom vendor-based OTLP-compatible collector**, or adding more rules to the telemetry processing pipeline.
36+
37+
Common Technical Specifications
38+
^^^^^^^^^^^^^^^^^^^^^^^^
39+
40+
- **Telemetry Collection**: Both platforms use the OpenTelemetry Collector or compatible OTLP collectors to gather telemetry data (metrics, traces).
41+
- **Endpoint Configuration**: Both platforms allow specifying endpoints for sending data, including local tools and external services like Grafana Cloud.
42+
- **Authentication**: External services require credentials (e.g., API tokens, access keys) for secure data transmission.
43+
- **Secure Communication**: Both platforms support encrypted communication channels for telemetry data transfer.
44+
- **Credential Management**: Platforms enable secure management of credentials for safe data forwarding to external services.
45+
- **Scalability**: Both platforms support scaling the telemetry stack, including the OpenTelemetry Collector and other observability components.
46+
- **Telemetry Configuration**: Both platforms allow fine-tuning settings for data collection, export formats, and the types of telemetry data.
47+
- **Flexible Deployment Options**: Both platforms support various configurations, from self-contained observability stacks to combining internal and external tools.

0 commit comments

Comments
 (0)